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Chapter  I 

INTRODUCTION 

The  ability  to  enhance  in  real  time  the  operational 
capability  of  a  deployed  weapon  system  has  been  a  long  term 
objective  of  weapon  system  users.  The  utilization  of  Embed¬ 
ded  Computer  Software  (ECS)  in  a  weapon  system  has  facili¬ 
tated  this  objective.  ECS  provides  the  ability  to  precisely 
tailor  a  weapon  system  to  specific  operational  requirements 
in  near  real-time.  ECS  is  that  software  that  is^an  integral 
part  of  an  electro-mechanical  system  embedded  in  a  weapon 
system  such  as  combat  weapon  system,  aircraft,  ship,  missile, 
spacecraft,  and  command  and  control  systems  (2:i).  As  a 
result  of  ECS's  enhancement  capability,  the  management  system 
to  be  utilized  for  ECS  is  of  equal  importance  to  both  the 
weapon  system  user(s)  and  any  organization  assigned  ECS 
support. 

In  considering  a  management  system  for  ECS,  three 
highly  visible  factors  associated  with  ECS  have  a  direct 
bearing  on  the  management  system  selected.  These  factors 
are  Life-Cycle-Costs,  software  configuration  control,  and 
responsiveness  to  changing  operational  requirements.  Con¬ 
cerning  Life-Cycle-Costs,  ECS  procurement  costs  are  estima¬ 
ted  to  be  one-fourth  to  one-fifth  of  the  entire  costs  asso¬ 
ciated  with  current  ECS  acquisition  (1:9).  In  addition,  the 
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percentage  of  total  weapon  system  costs  directly  attribu- 
-T&t51e~Cb  ECS'  is  'infcreasilT^'  aT  arC^xtrabrdlKar y"  rale  whil*e 
weapon  system  hardware  costs  are  decreasing.  Current  esti¬ 
mates  for  ECS  costs  are  illustrated  by  Figure  1. 
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Figure  1 

Percentage  of  Software  and  Hardware  Costs 
of  Total  System  Acquisition  Costs  (23:39) 


The  major  contributing  factor  to  Life-Cycle-Costs  is 
software  configuration  changes.  Typically,  a  previously 
believed  correct  and  tested  ECS  program  will  suddenly  pro¬ 
duce  wrong  results,  no  results,  behave  erratically  as  a 
result  of  stimuli  not  previously  addressed  nor  accounted 
for  in  the  programming  effort  (7:18).  This  situation  will 
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result  in  extensive  program  delays,  software  program  reit¬ 
erations,  and  ma:Vr“mbdi£icaVions^  ~?T’'Spec'if Ic'eX'ampre"  Is 
the  Strategic  Air  Command's  Automated  Command  Control  System 
where  errors  were  discovered  at  a  rate  of  one  per  day  and 
eventually  95  per  cent  of  the  software  had  to  be  rewritten 
(23:38).  For  another  system  currently  under  procurement 
consideration,  the  anticipated  ratio  was  fifteen  to  one  for 
software  changes  to  hardware  changes  (1:14).  ECS  change  re¬ 
sponsiveness  and  control  are  the  critical  considerations  in 
any  ECS  management  system  since  changes  are  critical  to  the 
successful  employment  of  a  weapon  system.  The  successful 
employment  of  a  weapon  system  is,  sometimes,  dependent  on 
the  support  organization's  ability  to  tailor  the  ECS  to 
operational  requirements  in  a  timely,  efficient,  and  effec¬ 
tive  manner.  Operational  requirements  are  user  determined 
and  responsiveness  to  these  requirements  is  a  major  factor 
in  ECS  management.  Responsiveness  is  defined  to  be  that 
time  from  the  identification  of  an  operational  requirement 
or  software  deficiency  to  the  return  of  the  weapon  system  to 
an  operational  state  with  the  appropriate  software  changes 
incorporated.  From  the  user's  viewpoint,  responsiveness  is 
the  deciding  issue  in  any  ECS  management  system.  For  users, 
the  criteria,  in  order  of  precedence,  for  evaluating  a  sup¬ 
port  organization's  responsiveness  effectiveness  is:  (1) 
timely  satisfaction  of  mission  requirements,  (2)  implementa¬ 
tion  of  DOD  policies,  and  (3)  effective  utilization  of  per¬ 
sonnel  and  weapon  system  (1:8)  . 
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The  AFLC  position  regarding  ECS  management  is  that 
*  tewar«»mt)s-t  tanned  •=««  pa#t  oi—the  overall  weapon—.  • 

system's  System  Management  and  System  Engineering  responsi¬ 
bility  (1:8).  However,  a  recent  AFLC  study  concerning  Com- 
munications-Electronics-Meteorological  systems  did  not 
address  the  current  AFLC  management  and  support  practices 
capability  of  providing  the  responsiveness  required  by  users 
(1:6).  Instead  of  addressing  software  responsiveness,  AFLC 
has  recently  issued  direction  to  utilize  hardware  management 
and  support  requirements  for  software.  Failure  to  recognize 
the  unique  characteristics  of  software  and  to  plan  to 
manage  it  as  "just  another  system"  negates  the  basic  bene¬ 
fits  of  ECS  (1:12) . 

In  order  to  obtain  the  most  economical,  efficient,  and 
effective  management  of  ECS,  reasonable  tradeoffs  are  re¬ 
quired  between  responsiveness  and  configuration  control. 

The  management  concept  utilized  should  treat  ECS  and  the 
weapon  system  as  an  integrated  entity  insuring  to  the  user 
maximum  design  flexibility,  responsiveness  to  mission  re¬ 
quirements,  weapon  system  integrity,  and  interoperability 
(1:12).  This  management  concept  to  be  utilized  for  software 
has  been  stated  as: 

This  policy  concerns  configuration  management  of 
computer  resources  in  major  defense  systems  .... 
Software  will  be  treated  as  a  full  fledged  configuration 
item,  with  all  required  disciplines,  controls,  and  test¬ 
ing  included.  The  emphasis  will  be  on  product  defini¬ 
tion,  requirements  traceability,  interface  definition 
and  control,  cost,  quality  traceability,  and  the  corol¬ 
lary  control  disciplines  C1:9J. 
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PROBLEM  STATEMENT 


Current  AFLC  Management  System  requirements'  for  posl^- 
Program  Management  Responsibility  Transferred  ECS  adversely 
affects  responsiveness  to  User  configuration  changes  for 
tailoring  a  weapon  system  to  an  operational  requirement. 

BACKGROUND 

Currently,  decisions  on  which  command  will  ultimately 
manage  ECS  have  been  made  on  a  case  by  case  basis  (31:9) . 

This  situation  is  due  to  the  strenuous  objections  placed  by 
weapon  system  users  to  the  centralization  of  ECS  management 
in  AFLC.  User  objections  focus  on  one  central  issue,  re¬ 
sponsiveness.  The  AFLC  approach  to  provide  responsiveness 
and  configuration  control  is  to  utilize  the  System  Manage¬ 
ment  concept  (1:10).  This  concept  functions  within  the 
existing  AFLC  hardware-oriented  roles,  missions,  regulations, 
and  policies  (1:7).  This  approach  to  software  management 
does  not  provide  the  degree  of  responsiveness  required  by 
users.  Traditionally,  this  inability  by  AFLC  has  been  at¬ 
tributed  to  inadequate  or  nonexistent  ECS  documentation. 
However,  users  do  not  seemingly  experience  a  similar  problem 
for  the  software  they  manage.  Each  major  command,  in  an 
evaluation  of  a  recent  proposal  for  centralization  of  Com¬ 
munication-Electrical-Meteorological  (CEM)  management  in 
AFLC,  identified  responsiveness  as  the  critical  issue.  AFLC 
did  not  and  does  not  address  this  deciding  user  issue. 
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JUSTIFICATION  OF  RESEARCH  EFFORT 


Software  design  is  extremely  complex,  requiring  exten¬ 
sive  self-documentation  and  program  readability  (23:39). 
Because  of  this,  software  management  is  personnel  dependent, 
program  documentation  dependent,  unrewarding,  and  stress  in¬ 
ducing.  This  management  complexity  is  further  complicated 
the  multi-command  management  responsibility  currently  util¬ 
ized  with  ECS.  This  complexity  has  accentuated  rhe  require¬ 
ment  for  the  total  system  management  of  a  weapon  system. 

ECS  needs  to  be  integrated  within  the  overall  system  manage¬ 
ment  function  of  the  weapon  system  (1:8).  In  AFLC ,  the  key 
elements  required  to  assure  that  user's  ECS  responsiveness 
requirements  are  attained  and  that  the  ECS's  configuration 
is  controlled  are  System  Management,  System  Engineering,  and 
System  Configuration  Management.  The  lead  function  is  Sys¬ 
tem  Management.  The  System  Management's  function  is  to 
assure  effective,  efficient,  and  economical  support  to  ECS 
users  that  is  responsive  and  within  economical  constraints. 
System  Engineering's  function  is  to  direct  and  control  the 
totally  integrated  engineering  effort  required  to  support 
all  aspects  of  the  weapon  system  (1:10).  The  dominant 
criteria  through  both  of  these  functions  is  the  assessment 
and  assignement  of  priorities  to  insure  consonance  between 
user's  responsiveness  requirements  and  AFLC  support  consi¬ 
derations  by  providing  the  responsiveness  and  control  re¬ 
quired  by  all  involved  organizations.  This  priorities 


assessment  and  assignment  is  to  be  accomplished  through 

.  nuLoim^l.  ..T-ayo-rJ. ; ,a.  of,  .par sncmp  1.  ani  Wiageceai.fcOOlS 

between  the  user  and  the  System  Manager  (1:13).  AFLC's  Con¬ 
figuration  Management  requires  that  the  software  be  thorough¬ 
ly  tested  and  verified  prior  to  approval  and  release.  The 
objective  is  incremental  rather  than  continual  software 
changes  that  are  optimally  allocated  to  the  appropriate 
hardware  or  software  subsystem.  In  addition,  potential  hard¬ 
ware  and/or  software  impacts  from  a  change  are  identified 
and  considered  prior  to  implementation.  This  is  done  so 
that  the  system's  integrity  and  supportability  is  preserved 
(1:10)  . 

In  meeting  these  AFLC  management  objectives,  the  user 
required  responsiveness  has  not  been  provided.  In  AFLC, 

ECS  is  the  lease  understood,  most  expensive,  and  least  relia¬ 
ble  component  of  an  operational  weapon  system  (7:20).  The 
AFLC  organization  structure  for  ECS  management  has  no  single 
management  focal  point.  This  lack  induces  fragmented,  in¬ 
effective,  and  inefficient  ECS  management  (2:ii).  Conse¬ 
quently,  there  cannot  and  does  not  exist  a  clear  responsi¬ 
bility  delineation  between  functions  ( 2 : i i ) .  This  condition 

culminates  in  the  current  AFLC  Configuration  Control  Boards' 
role,  function,  control,  and  authority  directly  impacting 
user  required  responsiveness  (1:18.6).  Concerning  the  actual 
software  maintenance  support,  AFLC  is  experiencing  difficul¬ 
ties  deciding  on  whether  that  support  should  be  organic  or 
contractor  (2:ii).  In  addition,  software  changes  released 


by  AFLC  are  receiving  inadequate  documentation  and  change 
eeviete- (■6^0)  The  inertsi^ity  -fccr'captEft y^ie’SSbn's  i^aftTed  from 
one  ECS  weapon  system  application  and  transfer  that  knowledge 
to  another  system  is  experiencing  difficulties  (1:16).  In 
this  instance,  required  documentation  is  inadequate  or  non¬ 
existent  and  if  available  does  not  comply  with  AFR  800-14 
(6:13).  Also,  AFLC  is  experiencing  personnel  problems  such 
as:  availability,  continuity,  morale,  tenure,  and  utiliza¬ 
tion  effectiveness  (1:15).  These  conditions  are  directly 
attributable  to  the  lack  of  a  definitive  HQ  AFLC  ECS  policy: 
specifically  the  areas  of:  configuration  management,  defi¬ 
ciency  reporting,  organizations*  responsibilities,  and 
human  resource  management  (2:i). 

SCOPE 

The  impetus  of  this  study  is  directed  towards  estab¬ 
lishing  the  required  relationships  that  should  exist  between 
AFLC  and  users  of  weapon  systems  having  ECS.  ECS  management 
practices  utilized  by  Tactical  Air  Command  (TAC) ,  Air  Force 
Logistics  Command  (AFLC) ,  and  the  National  Aeronautical  and 
Space  Administration  (NASA)  will  be  evaluated  in  terms  of 
responsiveness  and  configuration  control  in  order  to  deter¬ 
mine  those  relationships. 
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RESEARCH  OBJECTIVES 

...  ••  •  •  •  •  **  ■“  •  - 

1.  Establish  the  management  system  requirements  for  utili¬ 
zation  by  AFLC  in  providing  responsive  and  controlled  ECS. 

2.  Establish  the  organization  structure  that  should  exist 
based  on  those  determined  management  system  requirements. 

RESEARCH  QUESTIONS 

1.  What  are  the  current  responsiveness  and  configuration 
control  requirements  at  TAC,  NASA,  and  AFLC  and  determine: 

A.  What  are  the  deficiencies  in  each? 

B.  What  are  the  benefits  in  each? 

C.  What  configuration  control  and  responsiveness 
tradeoffs  have  been  made? 

2.  What  is  the  required  relationship  between  AFLC  and  users 


Chapter  II 


r« 


SOFTWARE  MANAGEMENT  PRINCIPLES 

Software  management  publications  were  researched  to 
determine  those  software  management  principles  that  would  be 
important  to  the  management  of  ECS  in  terms  of  responsive¬ 
ness  and  configuration  control.  The  principles  identified 
by  this  research  as  having  significant  impact  on  responsive¬ 
ness  and  configuration  control  are  briefly  discussed  here. 
These  principles  constitute  the  requirements  for  a  manage¬ 
ment  system  to  be  responsive  to  users  and  control  ECS  ade¬ 
quately.  A  more  extensive  discourse  of  the  requirements  for 
each  of  the  principles  as  they  relate  to  responsiveness  and 
configuration  control  is  provided  in  Appendix  A.  Both 
Appendix  A  and  the  discussion  here  address  the  relationships 
between  a  principle  identified  and  responsiveness  and  con¬ 
figuration  control,  exclusively.  There  is  no  attempt  to 
delineate  the  total  requirements  associated  with  each  prin¬ 
ciple,  their  development,  or  their  relationship  with  other 
principles.  The  reader  is  referred  to  Appendix  A  if  further 
review  of  the  principles  is  desired  beyond  what  is  provided 
here . 
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RESPONSIVENESS 


For  a  support  organization,  responsiveness  is  maintain¬ 
ing  the  management  system  capability  and  the  implemented 
support  philosophy  of  making  rapid  chanqe  to  ECS  that  is  re¬ 
quired  and  needed  in  the  user  environment.  The  objectives 
of  the  support  organization  are  that  changes  be  accomplished 
in  time  to  meet  users'  responsiveness  requirements  and  are 
effective  and  supportable  within  its  support  constraints. 

The  ability  to  provide  responsiveness  is  directly  impacted 
by  the  support  organization's  structure  and  by  its  applica¬ 
tion  of  its  philosophy  for  providing  that  support.  The  re¬ 
quired  responsiveness  is  dynamic  in  terms  of  change  priority 
assignment,  the  importance  of  that  change  relative  to  other 
in-coming  or  existing  actions,  and  the  current  and/or  future 
external  environment  conditions.  Responsiveness  is  detri¬ 
mentally  effected  by  the  corrective  action  accomplishment 
time  (which  is  a  function  of  existing  documentation,  number 
of  changes  previously  accomplished,  personnel  and  ECS  design) 
In  addition,  responsiveness  is  detrimentally  effected  by 
centralization  of  control  in  a  single  point  manager  who 
authorizes  a  change's  implementation.  An  ECS  management 
system  must  consider  each  of  these  responsiveness  facets  in 
its  development  if  it  is  to  maintain  its  viability  after 
development. 
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CONTROL 


The  ECS  control  philosophy  establishes  the  basis  for 
effective  responsiveness  and  configuration  control  of  ECS. 

The  objectives  are  to  (1)  centralize  maintenance  activities 
as  much  as  possible  in  order  to  maximize  efficiency  and  eco¬ 
nomy,  (2)  assur  users'  requirements  and  operations  are  not 
impaired  by  maintenance  activities,  and  (3)  establish  checks 
and  balances  between  users'  responsiveness  requirements  and 
the  support  organization's  control  requirements.  The  com¬ 
monality  of  the  control  philosophy  between  organizations  is 
fundamental.  The  extent  of  control  required  is  that  neces¬ 
sary  to  assure  that  ECS's  integrity,  suppor tability ,  oper¬ 
ability,  and  currency  is  maintained.  All  aspects  of  the 
control  philosophy's  implementation  necessitate  the  involve¬ 
ment  of  users  of  ECS.  The  control  must  extend  to  all  changes, 
whether  to  requirement  or  code,  whether  complex  or  simple. 

In  order  to  avoid  duplication  of  effort  and  conflicting 
authorizations,  the  control  over  ECS  should  be  focused  in  a 
single  point  with  all  authorizations  emanating  from  that 
single  point.  Management  system  activities  required  to 
assure  control  is  maintained  but  which  are  not  involved 
directly  in  the  resolution  activity  should  be  done  in  parallel 
and  not  sequentially.  When  tradeoffs  are  required  between 
responsiveness  and  control,  definite  governing  procedures 
must  be  concurred  in  by  the  users  and  the  support  organiza¬ 
tion.  In  order  to  assure  that  ECS  control  is  being  maintained 


and  that  that  control  is  not  adversely  affecting  responsive¬ 
ness,  specific  timeline  standards  must  be  maintained  for  all 
control  activities  and  appropriate  actions  must  be  taken  to 
modify  those  activities  when  evaluation  indicates  standards 
are  being  exceeded.  All  ECS  management  systems  must  address 
each  of  these  facets  of  control  if  they  are  to  be  responsive 
and  provide  adequate  control. 

COMMUNICATION 

Communication  is  critical  between  users  and  the  organ¬ 
ization  providing  ECS  support.  The  closer  the  interface 
between  users  and  the  support  organization,  the  more  effec¬ 
tive  is  the  responsiveness  and  control  of  the  management 
system.  Direct  interfaces  are  required  between  users  and 
support  personnel  in  order  to  assure  the  most  effective, 
timely  and  continuous  support.  Emphasis  must  be  on  real 
time  communication  between  these  individuals.  This  means 
that  there  should  exist  minimal  management  layering,  minimal 
in-house  coordination,  and  direct  real-time  communication 
links  between  the  support  organization  and  the  users.  Due 
to  this  make-or-break  nature  of  communication  between  users 
and  the  support  organization,  communication  is  a  critical 
element  and  as  such  should  be  reflected  in  the  management 
system's  development.  Any  cutoff  or  breakdown  of  communica¬ 
tion  seriously  effects  and  undermines  the  responsiveness  and 
control  effectiveness  of  the  management  system. 
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MANAGEMENT 


The  key  functions  in  ECS  management  are  to  Assure  (1) 
that  software  changes  are  optimally  allocated  to  the  appro¬ 
priate  system,  (2)  that  effective  maintenance  of  the  total 
weapon  system  is  performed,  (3)  that  potential  corollary 
impacts  from  changes  to  hardware  and  software  are  identified 
and  considered  before  implementation,  and  (4)  that  the  wea¬ 
pon  system's  integrity  and  operability  is  maintained.  These 
functions  require  that  all  organizations  involved  with  ECS 
support  have  their  responsibilities  clearly  and  specifically 
delineated.  This  includes  their  internal  departments.  A 
formal  structure  is  required  with  specific  identification 
of  contact  points  with  authority  and  coordination  respon¬ 
sibility  for  the  ECS.  Relationships  must  be  expressly 
identified  and  detailed.  Any  diffusion  of  responsibility, 
conflicts,  or  responsibility  encroachment  adversely  effects 
the  ability  of  the  ECS  to  be  supported  with  the  required 
responsiveness  and  configuration  control. 

DESIGN 

Software  design  in  terms  of  languages  utilized,  program 
complexity,  and  program  structure  directly  effects  respon¬ 
siveness  and  configuration  control.  The  greater  the  complex¬ 
ity  and  the  more  intricate  the  structure,  the  greater  the 
time  required  to  perform  corrective  action  and  the  risk  that 
that  corrective  action  performed  was  not  correct.  A 


management  system  that  does  not  give  consideration  to  the 
design  of  the  program  to  be  managed  but  specifies  management 
system  requirements  without  regard  to  the  program  managed 
will  adversely  effect  responsiveness  and  configuration  con¬ 
trol  as  well  as  operability,  maintainability,  and  integrity. 

PLANNING 

f 

The  lack  of  planning  as  generated  from  the  implemen¬ 
tation  of  the  support  philosophy  is  a  dominant  cause  of 
problems  in  ECS  control  and  failures  to  meet  responsiveness 
requirements.  Planning  is  the  implementation  of  the  control 
philosophy  by  which  the  support  organization  provides  respon 
sive  and  controlled  software  changes  to  the  users.  An  ef¬ 
fective  ECS  management  system  must  have  effective  planning 
for  individual  changes  and  changes  as  a  whole  in  order  to 
provide  the  responsiveness  and  control  required. 

DOCUMENTATION 

The  extent  and  level  of  documentation  required  in  an 
ECS  acquisition  is  hard  to  evaluate  and  determine  since 
shortcomings  in  the  procured  documentation  are  not  apparent 
until  a  need  exists.  The  fact  that  documentation  directly 
effects  a  support  organization's  ability  to  perform  cor¬ 
rective  action  necessitates  that  standards  and  minimum 
documentation  requirements  be  established.  In  terms  of 
maintenance  of  software,  as  maintenance  is  performed,  the 


difficulty  of  performing  additional  maintenance  rises  expo¬ 
nentially.  This  is  because  of  the  inadequate  documentation 
of  these  maintenance  activities.  All  maintenance  activities 
must  be  thoroughly  documented  and  controlled.  Lack  of  this 
control  adversely  effects  responsiveness  and  the  configura¬ 
tion  baseline  can  be  totally  lost.  Any  software  management 
system  must  have  minimum  documentation  requirements.  These 
requirements  are  developed  jointly  by  the  support  organiza¬ 
tion  and  the  acquisition  organization.  A  detailed  analysis 
of  documentation  requirements  is  not  included  in  this  effort 

REQUIREMENTS 

One  of  the  most  important  aspects  to  effective  response 
oriented  support  organizations  is  ECS  requirements  defini¬ 
tion.  ECS  requirements  generation  and  definition  are  depen¬ 
dent  on  the  user  and  as  such  require  the  total  involvement 
of  the  user.  Separation  of  the  users  from  the  development 
of  requirements  or  the  implementation  of  requirements  in¬ 
vites  misconception  and  erroneous  interpretation  of  ECS 
requirements.  This  separation  will  consequently  impact 
redponsiveness  and  configuration  control  as  the  released 
ECS  will  not  meet  operational  requirements  and  will  require 
delays  for  reprogramming  and  restructuring.  A  management 
system  addressing  responsiveness  and  configuration  control 
must  assure  the  integration  of  users  and  the  support  organ¬ 
ization  in  the  requirements  development  and  their  implements 
tion . 
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USER 


The  user  is  that  organization  that  has  the  operational 
needs  from  which  the  ECS  requirements  were  developed.  Only 
the  user  has  the  full  operational  knowledge  of  how  the  ECS 
will  be  employed.  ECS  that  is  maintained  (1)  with  only 
average  input  from  or  understanding  and  support  of  users  or 
(2)  by  those  with  whom  the  user  disagrees  philosophically  or 
management  wise  has  a  usage  failure  probability  rate  that 
rises  geometrically  with  lessening  user  support  and  partici¬ 
pation.  The  user  is  critical  to  all  aspects  of  the  ECS 
management  system  if  that  system  is  to  be  responsive  and 
maintain  effective  configuration  control  of  viable  programs. 
No  ECS  support  effort  can  be  initiated  and  accomplished  suc¬ 
cessfully  without  user  involvement  and  commitment  to  the  ECS 
requirements,  its  support  philosophy,  and  its  management 
system.  Responsiveness  and  configuration  control  cannot  be 
accomplished  wihout  the  initimate  support,  involvement,  and 
participation  of  users  in  the  management  system. 

TEST 

Testing  verifies  the  operability,  compatibility,  and 
integrity  of  the  software  to  be  released.  However,  there 
exists  no  theoretical  or  practical  way  to  prove  that  soft¬ 
ware  tested  is  absolutely  correct.  Testing  of  changes  to 
software  continues  to  the  extent  necessary  to  assure  that 


the  requirements  are  met  and  that  no  adverse  effects  result 
from  a  change.  The  time  required  for  testing  should  not 
adversely  effect  responsiveness. 

EXECUTIVE  STEERING  COMMITTEE 

This  committee's  responsibility  is  to  determine  the 
management  system  philosophy  for  support  organizations.  It 
specifies  by  its  philosophy  the  management  concept,  the 
organization  structure,  and  responsiveness  and  control  guide¬ 
lines  for  support  organizations.  This  committee  assures  that 
the  support  provided  is  consonant  with  its  philosophy  and 
guidelines.  Visible  evidences  of  an  Executive  Steering 
Committee  that  is  unwilling  or  unable  to  perform  these  func¬ 
tions  are  communication  problems  with  users,  change  priority 
problems,  and  management  layering  within  support  organiza¬ 
tions.  The  presence  of  these  results  in  control  and  respon¬ 
siveness  being  adversely  effected.  The  Executive  Steering 
Committee  is  identified  in  the  Air  Force  environment  as  a 
Major  Command  Headquarters  operation. 

PERSONNEL 

A  determining  factor  in  where  to  locate  the  single  point 
of  control  for  ECS  is  personnel.  The  personnel  factors  of 
availability,  continuity,  capability,  experience  and  orien¬ 
tation  are  the  determining  factors  as  to  which  organization 
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should  be  the  single  point  of  control.  The  organization 
that  can  satisfy  these  factors  best  is  the  organization 
which  should  be  the  single  point  of  control. 


Chapter  III 


MANAGEMENT  SYSTEMS  ANALYSIS 

Management  systems  currently  exist  which  were  developed 
to  provide  the  appropriate  degree  of  responsiveness  and 
configuration  control  for  Embedded  Computer  Software. 

Figure  Two  is  a  typical  management  system  that  provides  the 
appropriate  degree  of  responsiveness  and  configuration 
control  for  ECS.  In  this  context,  the  objectives  of  this 
analysis  will  be  the  determination  of  (1)  those  management 
system  functions  and  requirements  that  impact  responsive¬ 
ness  but  which  are  not  needed  by  either  responsiveness  or 
control  considerations,  (2)  those  management  system  func¬ 
tions  and  requirements  that  are  directly  attributable  to  a 
particular  management  philosophy,  and  (3)  those  management 
system  functions  and  requirements  that  are  due  to  control 
and  responsiveness  considerations. 

Research  Design 

Three  separate  and  distinct  management  systems  have  been 
selected  for  evaluation  in  order  to  determine  the  management 
system  requirements  needed  in  providing  responsive  and  con¬ 
trolled  ECS.  The  National  Aeronautics  and  Space  Administra¬ 
tion's  management  system  for  the  Space  Shuttle's  Mass  Memory 
software  utilizes  a  system  that  attempts  to  maximize  control 
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and  responsiveness  by  means  of  (1)  minimizing  time  delays 
due  any  cause  other  than  corrective  action  on  the  software, 

(2)  completing  testing  concurrently  with  utilization,  and 

(3)  focusing  baseline  and  control  in  a  central  point.  The 
Tactical  Air  Command,  United  States  Air  Force  Europe,  and 
Pacific  Air  Force,  utilizes  a  management  system  that  attempts 
to  maximize  control  and  responsiveness  by  means  of  (1)  mini¬ 
mizing  corrective  action  time,  (2)  maximizing  interface 
validation  and  testing,  and  (3)  focusing  baseline  control  in 
a  single  focal  point.  The  third  subject,  Warner  Robbins  Air 
Logistics  Center,  operates  under  the  Headquarters  Air  Force 
Logistics  Command  regulations  that  dictate  timely,  efficient, 
and  effective  logistics  support  that  is  cost  effective, 
mission  sustaining,  and  efficient.  Although  each  of  these 
organizations  vary  in  their  particular  management  system, 

all  have  as  common  goals  the  maximizing  of  responsiveness 
and  configuration  control  of  ECS.  The  composition  of  each 
organization's  management  system  was  determined  by  utilizing 
a  structured  interview  questionnaire  (Appendix  C)  and  the 
appropriate  organization's  management  system  documentation. 

The  structured  interview  questionnaire  was  selected 
because  this  technique  assured  all  areas  of  interest  were 
investigated  and  allowed  intense  investigation  of  areas  of 
interest  as  conditions  warranted.  This  technique  coupled 
with  the  organization's  documentation  provided  a  more  realis¬ 
tic  insight  to  the  actual  formation  of  requirements. 
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procedures,  standards,  and  practices  in  a  subject  organiza¬ 
tion.  It  also  provides  an  opportunity  to  explore  each 
aspect  of  a  management  principle  necessary  to  assure  respon¬ 
siveness  and  configuration  control. 

The  questionnaire  was  developed  by  reviewing  each 
principle  that  was  identified  in  Chapter  II.  Within  each 
principle,  those  factors  that  were  significant  or  were 
indicated  as  being  of  primary  concern  to  the  successful 
accomplishment  of  that  principle's  relationship  to  respon¬ 
siveness  or  configuration  control  were  detailed  as  a  ques¬ 
tion.  The  intent  was  not  to  restrict  information  but  to 
enhance  the  transfer  of  information  between  researcher  and 
interview  subject.  The  questions  are  general  in  order  to 
provide  an  atmosphere  conducive  to  the  determination  of  the 
actual  operation  of  a  subject  organization's  management 
system  and  its  responsiveness  and  control  requirements. 

The  emphasis  in  question  formation  was  on  the  capture  of  the 
total  intent  of  the  applicable  requirements. 


Management  Systems 
Simulation 

The  subject  organizations'  management  system  was  Simula 
ted  utilizing  the  computer  program  techniques  of  Q-GERT  (see 
Appendix  D) .  The  effort  was  to  establish  the  various  elapse 
times  for  each  organization’s  functions  to  response  to  a  TRW 
Command  and  Control  program  with  a  known  200  errors  in  4400 
instructions.  Each  node  and  activity  in  the  simulation 


corresponds  directly  to  a  documented  function  in  the  appro¬ 
priate  organization's  regulations,  requirements,  or  operating 
instructions.  The  elapsed  times  between  functions  are  purely 
hypothetical  and  are  not  intended  to  be  the  basis  for  eval¬ 
uating  the  performance  of  a  specific  function.  The  times 
are  based  on  actual  timeline  requirements  in  the  management 
system.  Each  model  is  a  reflection  of  those  activities  and 
functions  that  are  actual  elements  of  the  respective  man¬ 
agement  systems.  The  absolute  probabilities  and  routine 
times  determined  and  utilized  are  not  necessarily  accurate. 
However,  the  times  determined  are  valid  as  a  basis  for  com¬ 
paring  management  systems.  Changing  probabilities  and 
routing  times  to  reflect  actuals  (currently  not  available) 
would  not  appreciably  benefit  the  analysis  because: 

1.  The  analysis  of  a  specific  function  and  its  per¬ 
formance  is  limited  to  the  relative  impact  experienced  by 
the  management  system  from  that  function. 

2.  The  differences  between  the  management  system 
of  interest,  the  AFLC  management  system  and  the  other  man¬ 
agement  systems  is  of  sufficient  magnitude  that  "fine-tooth" 
refining  would  not  contribute  appreciably  to  the  analysis. 

Certain  assumptions  concerning  the  interarrival  rate  of 
changes  and  their  routing,  activity  time,  and  resolution 
time  were  made.  These  assumptions  are  identical  in  all 
three  models. 
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For  interarrival  rate  of  changes,  the  assumption  is 
that  the  rate  will  follow  the  Mean  Time  to  Failure  (MTTF) 
equation  derived  from  the  Shooman  exponential  reliability 
equation  which  is: 

MTTF  =  1/{C( (E/I)-e(t) ) ) 

This  equation  was  selected  based  on  an  evaluation  by  the 
Rome  Air  Development  Center  (RADC)  of  this  equation  to 
reliably  predict  failures.  In  this  equation,  the  variable 
was  set  at  one.  This  variable  is  the  proportionality  con¬ 
stant  derived  from  the  amount  of  testing  accomplished  prior 
to  the  initiation  of  corrective  action  for  current  changes. 
The  variable  E  is  the  number  of  errors  currently  existing 
in  the  program.  This  variable  was  set  at  200  errors  in  ac¬ 
cordance  with  the  program  under  test.  The  variable  I  which 
is  the  total  number  of  instructions  in  the  program  in  the 
experiment  was  set  at  4400.  The  variable  function  e(t) 
is  the  quantity  of  errors  corrected  during  some  elapsed 
time  t.  The  variable  e(t)  was  determined  at  the  function  in 
the  management  system  where  corrective  action  was  actually 
initiated  and  not  just  reported  or  processed. 

Change  routing  in  each  model  was  based  on  the  following 
criteria: 

1.  All  routes  were  given  an  equal  probability  unless 
a  specific  route  had  been  identified  during  interviews  as 
receiving  negligible  activity. 
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2.  Changes  were  routed  so  that  all  possible  paths 
would  be  utilized. 

3.  Approval  action  by  the  various  control  boards 
was  favored. 

4.  The  elapsed  time  for  a  particular  activity  was 
described  in  activity  by  the  applicable  organization's  docu¬ 
mentation. 

Corrective  Action  Time  (Isolate,  Fix  and  Document  times) 
of  the  various  activities  is  based  on  the  work  of  Goel  and 
Ukmoto  for  RADC.  Based  on  their  research  of  improper  main¬ 
tenance  efforts,  which  was  theoretically  substantiated  by 
Captain  Sukert  of  RADC,  the  following  equations  were  selected: 

E 

ET  -  Cl/p)  (Z  1/UJ) 

J«N0+1 

VAR  (ET)  =  l/pZ  (Il/UJ)^ 

J=N  +1 
o 

The  variable  p  in  the  equation  is  the  probability  that  proper 
corrective  action  was  accomplished  on  the  change  processed. 
This  variable  is  obtainable  from  Janson's  structural,  docu¬ 
mentation,  integrity,  and  complexity  equation  but  for  these 
models  was  set  at  .9.  The  variable  is  the  failure  occur¬ 
rence  rate  and  is  the  inverse  of  the  Shooman  Equation  pre¬ 
viously  discussed.  The  variable  NQ  is  the  number  of  errors 
remaining  uncorrected  at  some  time  t.  The  variable  NQ  and 
e(t)  (from  the  Shooman  exponential  reliability  equation)  are 
directly  related  and  are  determined  at  the  same  instant.  The 
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variable  E  is  the  same  as  in  the  Shooman  equation.  The 
variable  ET  is  the  expected  time  to  perform  the  corrective 
action  for  (E-NQ)  errors  by  personnel  who  are  90%  capable  of 
performing  the  activity  properly  when  those  errors  are  occur¬ 
ring  at  a  A  rate.  The  variable  VAR (ET)  is  the  variance 
associated  with  this  expected  time.  This  particular  set  of 
equations  was  selected  because  the  corrective  action  time 
is  a  function  of  the  number  of  changes  corrected  and  of  the 
point  in  the  management  system  that  that  action  is  taken. 
Utilization  of  these  equations  was  as  follows: 

1.  For  change  diagnosis  and/or  problem  isolation, 
the  value  determined  for  ET  was  used. 

2.  For  changes  requiring  a  documentation  change 
only,  the  value  determined  for  ET  was  used. 

3.  For  change  implementation,  a  G  vnma  distribution 
was  used  with  the  mean  equal  to  ET  and  the  standard  deviation 
equal  to  -4  VAR ( ET)  . 

Simulation  Results 

Tables  1,  2,  and  3  are  listings  of  the  results  from  the 
simulation  of  the  three  management  systems  under  investiga¬ 
tion.  The  title  of  a  particular  entry  is  related  to  a  parti¬ 
cular  function  in  the  applicable  management  system.  The  time 
entries  are  related  to  the  hours  elapsed  in  the  simulation 
from  the  initial  receipt  of  a  change  to  the  initation  of  that 
function's  activity.  The  two  columns  of  means  and  standard 
deviations  are  related  to  whether  or  not  a  particular 
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TABLE  1 


NATIONAL  AERONAUTICS  AND  SPACE  ADMINISTRATION 
SIMULATION  RESULTS 


Mean 


Std.  Dev. 


Mean 


Std.  Dev. 


IBM  Action  Time  31.7289 
Quick-Look  Report 
Requirement  Change 


1.3689 


Evaluation 

744.4682 

552.2257 

Level  III  CCB 

2631.8967 

405.8475 

Appeal  OASCB 

No  Appeal 

2634.6167 

589.3351 

OASCB  Wait 

2967.1115 

366.6585 

(3)  Emergency  Change 

OASCB 

57.3015 

25.4288 

Approval 

Disapprove 

94.2372 

49.5666 

0  TS.0  Board 

50.7834 

5.1155 

Test/Facility 

Unique  Change 

OASCB 

83.1415 

12.8275 

(5)  Permanent  Change 

Discrepancy 

Report 

47.7059 

12.5192 

Fix  Discrepancy 

400.4092 

436.1064 

Waiver 

228.2155 

68.3481 

J)  OASCB 

638.7953 

221.5906 

(7)  Mass  Memory  Release  Coordination 

616.6719  177.0161 

Release  Build 

783.6197 

177.6570 

Software  Release 

796.2309  177.0275 


User 


42.2419 
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2401.8561  487.9230 


56.6199  14.3172 


807.9521  177.1572 


TABLE  2 


TACTICAL  AIR  FORCES 
SIMULATION  RESULTS 


Mean  Std.  Dev.  Mean  Std. 


(Ty  CPCSB 

No  Action  Required 


47.8850  4, 


Implement  Change 

-  No  Impact 

61.7845  9.3481 

Change  Assessment 

58.3911 

8.2456 

(f  TAF  CCB  Emergency  71.9910 

Emergency  Implement 

17.3139 

130.4472 

27. 

( T  TAFIG 

Evaluation 

AFLC  SM/IM  Cood. 

54.3917 

100.9940 

197.3004 

8.2335 

20.7900 

17.7711 

TAF  CCB 

Disapprove 

323.7698 

52.7037 

354.9242 

60. 

(?  TAF  Baseline  Impact 
Downgrade  Class  II 

363.9601 

Joint  Stnd  Bd  352.9906 

Stnd  Impact  364.8724 

Disapprove 
Higher  HQ  Action 
Approved  Change-Test 

587.9209 

(s'  TAF  Baseline  Impact  Assessed 
Implement  323.5193 

Joint  Test  Required 
Joint  Test  Force 

472.0060 
Test  Failure  659.0576 

Test  Success  762.7238 

No  Joint  Test  644.3791 

Testing 

Test  Rqmts 
Test  Evaluation 

1060.3709 

(7s  Release  Version  869.5811 

(jT  User 


101.3319 

106.9564 

104.8570 


225.5037 

35.7096 


97.2893 

164.5707 

94.4880 

97.3060 


401.6684  143 

531.0835  102 


671.2421  212.4967 

237.3199 
188.7473 


890.1693  188 
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TABLE  3 


WARNER  ROBINS  LOGISTICS  CENTER 
SIMULATION  RESULTS 


Mean 

Std.  Dev. 

Mean 

Std.  Dev 

(D  <D 

Initial  Processing 

Arrival  .6137 

Reroute  CAT  I 

.1721 

2.0541 

1.1116 

Reroute  CAT  II 

SM/IM  MIP  Clerk 

13.6714 

.8400 

16.9969 

2.8893 

Technician  Review 

18.0650 

2.9382 

CPSP  29.6874 

2.6329 

CAT  I  Response 

24.6413 

.3719 

CAT  II  Response 

MMECT  Review  41.4418 

2.1010 

104.7149 

4.7470 

<D  @ 

Computer  Program  Control 

Sub-Board 

Transfer  Responsibility 

1031.7495 

281.8839 

Disapprove 

Approve  1123.3936 

55.7468 

1823.0839 

328.5522 

©  @ 

Configuration  Control  Board 

Disapprove 

Approve  2040.6511 

37.0488 

1948.4690 

303.8037 

Funding  Constraint 

HQ  AFLC  Action 

Disapprove 

1457.3656 

424.3656 

In-House  Determination 

837.5193 

202.1883 

Contractor 

Inhouse 

2986.8867 

68.3569 

Fix/Change 

2291.3860 

358.4516 

Pelim  Design 

2537.0158 

280.1771 

Detail  Design 

2574.2568 

113.4502 

Code/Test 

2878.5033 

90.5891 

Validate 

2964.5467 

171.7589 

Kit  Proof 

3114.2665 

361.6544 

0 

Computer  Program  Control 

Sub-Board 

3227.3776 

305.8933 

0 

User 

3156.4887 

242.3773 

All  Emergencies  Downgraded  to  Routine,  (l) 
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function's  activity  was  a  terminal  step  or  whether  another 
activity  followed.  If  a  terminal  step,  the  times  determined 
were  entered  in  the  third  and  fourth  columns.  If  another 
function  followed,  the  times  determined  were  entered  in  the 
first  and  second  columns.  The  circled  numbers  are  indicators 
of  similar  functions  in  the  various  management  systems. 

Based  on  simulated  elapsed  response  time,  the  Tactical 
Air  Force  management  system  is  the  best  management  system 
for  ECS.  This  is  because  of  the  Tactical  Air  Force's  man¬ 
agement  system's  ability  to  address  both  requirement  changes 
and  design  changes  in  less  time  than  in  the  other  two  systems 
While  the  NASA  response  time  is  better  for  design  changes 
(807  elapsed  hours) ,  the  impact  of  a  required  change  on  this 
system  is  significant  (2967  elapsed  hours) .  Of  the  three 
management  systems,  the  Warner  Robins  Air  Logistics  Center 
system  is  the  most  unresponsive  (3156  elapsed  time  regard¬ 
less  of  type  change) .  The  impact  of  a  particular  organiza¬ 
tion's  management  philosophy  is  also  quite  apparent.  In 
the  Tactical  environment,  64%  of  the  total  elapsed  time  in 
accomplishing  a  change  is  in  testing.  This  is  consistent 
with  the  Tactical  environment's  concept  of  assuring  via 
estensive  testing  the  interoperability  and  compatibility  of 
of  interfacing  systems.  In  the  NASA  environment,  80%  of  the 
total  elapsed  time  in  accomplishing  a  change  is  prior  to  the 
OASCB.  This  is  consistent  with  the  OASCB  management  philoso¬ 
phy  of  assuring  the  correct  content  and  maintainability  of 
software  released  to  a  user.  The  major  elapsed  time 
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consumers  in  the  NASA  environment  are  those  organizations 
which  have  been  delegated  responsibility  to  verify,  maintain, 
and  correct  their  subprograms  within  approved  requirements. 

In  the  Warner  Robins  environment,  65%  of  the  total  elapsed 
time  is  expended  prior  to  the  CCB.  The  impact  of  this  con¬ 
dition  on  responsiveness  is  significant  because  in  both  the 
Tactical  and  NASA  environment  the  time  spent  prior  to  the 
CCB  is  in  corrective  action  accomplishment.  In  the  Warner 
Robins  case,  this  CCB  authorization  is  to  commence  the  work 
that  both  of  these  other  organizations  have  completed  by  this 
point.  The  processing  time  in  the  Warner  Robins  management 
system  subsequent  to  CCB  approval  (1116  elapsed  hours)  com¬ 
pares  favorably  with  that  of  the  other  two  management  systems 
(800  elapsed  hours)  in  performing  corrective  action. 

The  greater  elapse  time  required  in  the  AFLC  environ¬ 
ment  in  performing  corrective  action  is  partially  attribu¬ 
table  to  its  interpretation  of  change  blocking.  The  AFLC 
interpretation  is  that  sufficient  quantities  of  changes  be 
held  in  abeyance  for  three  months  and  corrective  action  per¬ 
formed  concurrently  on  these  changes.  In  NASA  and  the  Tacti¬ 
cal  environments,  change  blocking  is  a  function  of  individual 
change's  priority.  In  the  NASA  and  Tactical  environments,  the 
time  expended  in  corrective  action  was  350  and  62  elapsed 
hours  respectively.  The  greater  NASA  time  was  due  to  manage¬ 
ment  layering  between  the  initial  report  and  the  corrective 
action  initiation.  In  the  Warner  Robins  environment,  the 
elapsed  time  was  1116  hours.  This  difference  is  attributable 
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to  its  management  layering  and  its  change  blocking  concept. 
These  results  are  directly  in  keeping  with  the  equations 
utilized  which  stipulate  that  the  corrective  action  time 
requirement  increase  exponentially  as  management  layers  in¬ 
crease,  as  the  location  of  the  corrective  action  is  physi¬ 
cally  removed  from  the  location  of  initial  reporting  of  a 
problem  or  change  requirement,  and  as  the  quantity  of  changes 
corrected  increases.  The  validity  of  this  simulation  sta¬ 
tistics  is  confirmed  by  the  increasing  need  by  the  Air  Logis¬ 
tics  Centers  providing  ECS  support  to  expand  their  timelines 
for  software  maintenance  releases. 

The  rapid  turnaround  times  provided  by  the  simulation 
in  both  the  NASA  and  the  Tactical  environments  substantiate 
the  importance  of  having  the  participation  of  the  users  in 
the  processing  of  a  change.  The  ability  in  the  Tactical 
environment  to  accomplish  corrective  action  at  an  early 
time  (58  elapsed  hours)  is  attributable  to  the  location  of 
users  in  their  Computer  Program  Control  Sub-boards.  In  the 
NASA  environment,  the  ability  to  quickly  identify  the  required 
action  for  a  particular  change  (31  elapsed  hours)  is  attri¬ 
butable  to  the  location  of  personnel  at  the  users  facility. 

In  the  Warner  Robins  environment,  the  users  are  not  involved. 
This  lack  contributes  to  the  elapsed  corrective  action  time 
requirement  being  1123  hours. 
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Management  Systems  Simulation 
Conclusions 

Based  on  the  similarity  of  activities,  the  needed  func¬ 
tions  in  a  management  system  are: 

(1)  a  group  comprised  of  users,  System  Management 
personnel,  and  Engineering  personnel  to  evaluate  the  required 
responsiveness  for  a  change, 

(2)  a  control  board  to  determine  the  required  action 
on  the  change, 

(3)  a  group  to  perform  the  required  action,  and 

(4)  a  control  board  to  authorize  release  of  corrected 
software. 

All  other  findings  outside  these  four  are  extraneous  and 
impact  responsiveness.  In  the  Tactical  and  NASA  environ¬ 
ments  these  functions  are  present  with  minimal  management 
layering,  direct  real  time  interface  communication,  and 
minimal  change  priority  problems.  The  same  is  not  true  in 
AFLC.  For  the  AFLC  management  system  these  needed  functions 
are  found  in  the  existing  Computer  Program  Screening  Panel, 
the  Computer  Program  Control  Sub-board,  the  MMEC  function, 
and  the  ALC's  CCB.  All  other  functions  outside  these  basic 
functions  should  have  either  negligble  impact  on  the  manage¬ 
ment  system  or  perform  their  activities  in  parallel  with  these 
functions. 

The  blocking  concept  as  presently  utilized  in  AFLC 
and  simulated  in  the  model  is  adversely  affecting  the  ability 
of  this  management  system  to  be  responsive  to  change  action 


requirements.  However,  in  order  to  reduce  the  magnitude  of 
the  impact  of  this  concept  all  three  aspects  of  this  problem, 
that  is  management  layering,  direct  interface  capability,  and 
priority  change  blocking,  must  be  changed. 

Since  the  amount  of  time  expended  by  Warner  Robins  prior 
to  CCB  action  is  effort  that  will  have  to  be  duplicated  sub¬ 
sequent  to  the  CCB  approval  of  a  change,  all  actions  asso¬ 
ciated  with  this  time  should  be  eliminated.  The  numerous 
functions  during  this  time  only  complicate  the  corrective 
action  process  by  extending  processing  time.  These  functions' 
activities  must  be  performed,  if  at  all,  without  an  adverse 
impact  on  the  management  system.  In  particular: 

1.  The  function  of  receiving  change  requirement 
reports  in  the  management  system  is  not  required.  This 
function  only  adds  time  to  the  processing  and  the  review  it 
performs  must  be  accomplished  subsequently  by  other  functions. 
In  addition  to  this  function,  the  review  to  determine  the 
responsible  System  Manager  function  does  not  contribute  to 
the  resolution  of  the  corrective  action  required.  The  point 
where  identification  of  the  required  effort  for  a  change  is 
in  the  Materiel  Management  Engineering  Division  (MMEC) . 

After  this  review,  a  determination  is  made  of  the  required 
corrective  action.  The  Computer  Program  Screening  Panel 
function,  which  is  currently  structured  prior  to  the  MMEC 
function,  should  be  accomplished  subsequent  to  the  MMEC 
function  in  order  that  a  viable  disposition  recommendation 
can  be  made.  Placing  the  Computer  Probram  Screening  Panel 


35 


activity  subsequent  to  the  MMEC  review  would  eliminate  the 
1123  non-resolution  processing  hours  in  the  AFLC  management 
system.  This  change  is  in  harmony  with  reducing  management 
layers  and  providing  direct  interface  capability  by  locating 
the  activity  for  resolving  a  required  corrective  action  as 
close  as  possible  to  the  initial  reporting  of  the  problem. 

2.  Composition  of  the  Computer  Program  Screening 
Panel  must  be  expanded  to  include  the  users.  This  enhances 
the  direct  interface  capability  with  those  to  whom  support 
is  being  provided.  The  corrective  action  elapsed  time 

can  also  be  benefitted  in  terms  of  determining  the  extent  of 
testing  required,  the  needed  corrective  action,  the  users 
priority  for  the  change,  and  the  specific  change  requirements 
The  impact  of  this  participation  would  decrease  processing, 
testing,  and  corrective  action  time. 

3.  Based  on  the  determination  by  the  Computer  Pro¬ 
gram  Screening  Panel,  a  viable  recommendation  can  be  made 
to  the  Computer  Program  Control  Sub-board  on  each  change. 

The  objective  of  this  board  must  be  to  determine  (1)  whether 
contractor  action  is  required  to  correct  the  problem  or  an 
in-house  effort  will  suffice  and  (2)  whether  the  required 

“A 

funding  of  the  change  is  within  the  Air  Logistic  Center's 
authorization.  Based  on  these  interrelated  determinations, 
the  board  can  authorize  action  to  be  initiated  as  an  in-house 
effort,  or  as  a  requirement  determination  effort  prior  to 
contractor  support,  or  obtain  funding  from  HQ  AFLC  after 
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approval  by  its  CCB.  Specific  testing  requirements  should  be 
determined  at  the  Computer  Program  Screening  Panel.  Tradeoffs 
between  testing  performed  by  the  users  subsequent  to  release 
and  that  required  by  AFLC  should  be  negotiated  with  the  ob¬ 
jective  of  minimizing  testing  duplication.  In  the  NASA  en¬ 
vironment,  only  required  testing  is  accomplished  and  that  is 
determined  in  conjunction  with  the  users.  The  benefits  of 
this  testing  determination  action  to  the  Air  Logistics 
Center  would  be  a  reduction  in  change  processing  time. 

For  those  changes  involving  new  requirements,  there 
does  exist  considerable  time  delay  associated  with  new  re¬ 
quirement  support  regardless  of  the  management  system.  In 
the  NASA  environment,  considerable  time  (2967  elapsed  hours) 
was  expended  in  this  effort.  This  is  due  to  the  ECS  re¬ 
quirement  generation  coordination  requirements  of  the  man¬ 
agement  system.  In  the  Tactical  environment,  there  was  no 
delay.  This  is  due  to  the  fact  that  the  development  of  soft¬ 
ware  in  the  Tactical  environment  is  an  in-house  effort  and 
as  such  would  not  involve  the  delays  associated  with  obtain¬ 
ing  contractual  support.  However,  the  NASA  management  system 
is  a  substantial  improvement  over  the  AFLC  capability  due  to 
its  minimal  management  layering  and  direct  interface  with 
users. 

The  function  of  the  Air  Logistics  Center’s  CCB  should 
be  authorization  of  (1)  contractor  performed  work,  (2)  all 
software  releases,  and  (3)  all  changes  exceeding  funding 
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constraints  which  require  HQ  AFLC  approval.  This  authoriza¬ 
tion  should  be  provided  when  the  requirements  for  the  contrac¬ 
tor  have  been  specifically  delineated  and  agreed  to  by  users, 
just  prior  to  software  release,  or  prior  to  seeking  funding 
approval  dictated  by  the  appropriate  stiuation. 

It  can  be  concluded  from  the  philosophy  policy  of  the 
Warner  Robins  management  system  its  structure  and  implemen¬ 
tation  that  a  basic  reorientation  in  this  management  imple¬ 
mentation  system  is  required.  The  implementation  of  its 
management  philosophy  has  to  be  committed  to  the  mission  capa¬ 
bility  requirements  of  ECS  users  and  to  assuring  that  soft¬ 
ware  released  is  in  compliance  with  those  requirements. 
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Chapter  IV 


SOFTWARE  MANAGEMENT  PRINCIPLES 
RELATIONSHIPS  DETERMINATION 
AND  MANAGEMENT  SYSTEM 
IMPACT  ASSESSMENT 

The  application  of  the  software  management  principles 
stated  in  Chapter  II  in  an  ECS  management  system,  dictate 
the  responsiveness  and  control  to  be  experienced  by  that 
management  system.  The  purpose  here  is  to  (1)  determine  the 
relationship  between  software  management  principles  which 
affect  responsiveness  and  configuration  control,  (2)  deter¬ 
mine  the  required  applications  of  these  principles  to  an 
ECS  management  system,  and  (3)  identify  those  principles 
by  that  particular  management  system  function.  These  deter¬ 
minations  will  be  based  on  a  model  management  system  that  is 
comprised  of  the  four  basic  management  system  functions 
exclusively. 

Determination  Analysis 
Technique 

The  sources  researched  previously  for  the  software  man¬ 
agement  principles  were  utilized  to  determine  causal  relation¬ 
ships  between  individual  software  management  principles. 

The  purpose  was  to  determine  those  factors  that  constituted 
a  principle.  This  was  accomplished  by  reviewing  each  source 
and  identifying  specified  causal  relationships.  It  was 
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assumed  that  a  specified  causal  relationship  cited  by  a 
source  for  an  applied  principle  was  valid.  Relative  weights 
were  determined  for  each  factor  of  an  applied  principle  by 
assigneing  a  value  of  one  to  each  causal  relationship  appli¬ 
cable  to  that  principle,  aggregating  the  identified  causal 
relationships  by  factor,  summing  the  aggregates,  and  then 
dividing  each  aggregate  by  this  sum.  Relative  weights  so 
derived  indicate  the  relative  impact  of  that  particular  factor 
on  the  applied  software  management  principle  in  question. 

In  order  to  reduce  bias  from  any  one  source,  each  source's 
causal  relationships  and  their  corresponding  relative  weights 
for  a  particular  applied  software  management  principle  pro¬ 
vided  by  one  source  were  given  the  same  consideration  as 
those  provided  by  all  other  sources.  Factors  and  their 
corresponding  relative  weights  for  a  particular  applied 
software  management  principle  from  one  source  had  an  equal 
contribution  to  the  resulting  composite  relative  weight  for 
an  applied  principle  as  those  from  other  sources.  These 
relative  weights  for  an  applied  software  management  princi¬ 
ple  were  determined  utilizing  a  computer  Fortran  program 
(Appendix  E) .  Table  4  is  a  listing  of  those  composite  rela¬ 
tive  weights  so  derived.  The  "I"  in  any  relative  weight 
block  indicates  an  initial  factor  in  the  management  system. 

An  initial  factors,  or  exogenous  variables,  is  the  standard 
operating  procedures  of  a  management  system.  These  initial 
factor's  compliance  with  its  software  management  principles 
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TABLE  4:  FACTOR  COEFFICIENTS 


requirements  vary  and  can  be  utilized  to  determine  the  degree 
of  compliance  an  applied  principle  has  in  the  management  sys¬ 
tem  to  the  software  management  principles.  This  compliance 
is  reflected  in  the  management  system's  dynamics.  Since 
there  does  exist  an  extensive  interrelationship  between  the 
various  applied  software  management  principles,  any  pertur¬ 
bation  of  one  applied  principle  will  have  an  affect  on  the 
others.  The  relative  weights  derived  are  not  absolute  but 
are  a  linear  representation  of  the  actual  relationships.  If 
error  does  exist,  it  will  be  in  the  fact  that  a  factor  behaves 
exponentially  rather  than  linearly.  The  exponential  nature 
of  a  factor  stated  by  one  source  was  ruled  out  if  it  was 
not  substantiated  by  any  of  the  other  sources. 

The  modeling  simulation  techniques  of  Dynamo  were  util¬ 
ized  to  determine  the  required  application  of  software  man¬ 
agement  principles  to  an  ECS  management  system.  This  was 
performed  by  developing  equations  relating  the  four  basic 
functions  in  a  management  system  as  levels  of  the  management 
organization  and  utilizing  as  levels  of  activity  for  these 
functions  the  rates  utilized  in  the  Q-GERT  simulation  (Appen¬ 
dix  D)  management  system.  The  relationship  of  the  various 
applied  software  management  principles  to  the  management  sys¬ 
tem  was  in  the  form  of  information  flow  into  the  appropriate 
function.  This  is  because  an  applied  principle  does  not  have 
a  specific  level  of  activity  associated  with  it  but  it  does 
affect  the  degree  of  activity  of  a  management  system  function. 
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Those  applied  software  management  principles  affecting  a 
particular  management  system  function  were  identified  from 
the  responsibilities  of  the  applicable  function  as  detailed 
in  the  AFLC,  NASA,  and  Tactical  management  system  documenta¬ 
tion.  Equations  specifying  the  relationships  between  soft¬ 
ware  management  factors  and  applied  software  principles  were 
based  on  Table  3.  The  interface  between  the  management  sys¬ 
tem  and  the  appropriate  applied  software  management  princi¬ 
ples  was  accomplished  by  utilizing  a  combining  step.  This 
combining  step  integrated  the  applied  software  management 
principles  involved  with  a  particular  function.  The  com¬ 
bining  step  gave  equal  weight  to  each  involved  applied  prin¬ 
ciple.  This  equal  weighting  of  applied  software  management 
principles  for  each  function  was  based  on  the  assumption  that 
each  software  management  principle  was  required.  No  applied 
principle  was  identified  as  needing  additional  emphasis  in 
the  management  system  documentation.  The  Dynamo  simulation 
program  is  listed  in  Appendix  F. 

Initial  Factors  Management 
System  Impacts 

The  software  management  principles  identified  as  exogen- 
eous  variables  (initial  factors)  were  assigned  in  Table  4 
several  values  to  simulate  varying  degrees  of  compliance  with 
the  requirements  of  that  software  management  principle. 
Accordingly,  full  compliance  was  one,  half  was  .5,  and  no 
compliance  was  .1.  During  any  simulation  run  only  one  initial 
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factor  varied  while  the  remainder  were  held  constant  at  full 
compliance.  By  this  method,  isolation  of  the  effects  on  the 
responsiveness  and  control  of  the  management  system  (in 
terms  of  hours  required  to  make  a  change)  due  to  an  initial 
factor  could  be  identified.  Table  5  is  a  listing  of  those 
results  of  these  simulations  for  each  exogeneous  variable. 

For  each  exogeneous  variable,  there  are  two  entries  for 
each  function  of  the  management  system.  The  first  (.5) 
specifies  the  relative  effect  of  the  variable  of  interest 
on  the  curve  describing  that  particular  function's  level 
of  activity  from  that  when  the  factor  was  at  full  compliance. 
The  second  entry  (.1)  specifies  the  relative  effect  of  the 
variable  of  interest  on  the  curve  describing  that  partic¬ 
ular  function's  level  of  activity  with  respect  to  that 
function's  level  of  activity  when  the  variable  had  a  value 
of  .5.  Each  initial  factor  impacts  applied  principles  which 
in  turn  directly  impact  responsiveness  and  configuration 
control.  The  reduction  in  compliance  of  an  initial  factor 
and  its  resulting  impact  on  the  applied  principles  produces 
the  dynamic  nature  of  the  management  system  modeled. 

The  only  initial  factor  with  an  impact  on  the  management 
system  for  the  Software  Engineering's  level  of  activity  was 
Testing.  The  remainder  of  the  variables  indicated  no  impact 
regardless  of  value.  For  Test,  degradation  of  ECS  testing 
or  failure  to  test  ECS  would  result  in  a  constant  increase 
in  the  level  of  activity  for  the  Software  Engineering  func¬ 
tion.  The  degree  of  constant  increase  would  be  independent 
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TABLE  5:  EXOGEN EOUS  VARIABLE 
GROUP  LEVEL  IMPACT 
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Geometric  Decrease 
Exponential  Increase 
Geometric  Increase 


of  other  degradations  in  Testing.  Each  degradation  in  the 
Testing  principles  describes  an  individual  effect  on  the 
management  system.  Since  it  is  a  constant  increase  over  any 
value  of  degradation  of  the  Testing  principle,  there  is  no 
exponential  growth  in  the  level  of  activity  for  the  Software 
Engineering  function.  If  a  degradation  of  Testing  was  accom¬ 
plished  for  some  management  reason,  the  impact  of  that  degra¬ 
dation  on  the  Software  Engineering  function  would  not  be 
sufficient  to  warrant  the  precluding  of  that  management 
action. 

For  the  Screening  Panel  level  of  activity.  Test,  Control, 
Executive  Steering  Committee,  Design,  Communication,  Docu¬ 
mentation,  and  User  had  an  effect  on  the  management  system. 

The  effect  of  Test  on  the  management  system  was  the  same  as 
in  the  Software  Engineering  stage  and  the  same  conclusions 
there  are  valid  here.  For  Control,  the  further  degradation 
of  this  variable  to  .1  resulted  in  no  further  change  from 
the  level  of  activity  described  when  the  variable  was  at  .5. 
This  would  indicate  that  there  is  a  critical  point  in  the 
Control  initial  factor  that  affects  the  Screening  Panel  but 
subsequent  to  that  point  that  no  further  impact  is  experi¬ 
enced.  Degradation  of  the  Control  initial  factor  is  not 
precluded  based  solely  on  its  impact  on  the  Screening  Panel 
stage.  The  variables  of  Executive  Steering  Committee  and 
Design  both  exhibited  the  same  characteristics.  The  geomet¬ 
ric  decreases  affect  of  these  initial  factors  on  the 
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management  system  indicate  that  degradations  of  these  two 
variables  would  enhance  the  level  of  activity  for  the  Screen¬ 
ing  Panel.  Any  enhancement  in  the  level  of  activity  by  these 
variables  at  an  initial  stage  of  the  management  system  will 
have  an  exponential  increase  impact  on  a  subsequent  stage  of 
the  management  system.  This  is  realized  as  an  exponential 
impact  on  the  Corrective  Action  stage  of  the  management 
system.  Accordingly,  any  degradation  of  these  two  initial 
factors  which  would  be  beneficial  to  the  Screening  Panel 
would  be  severly  detrimental  to  the  Corrective  Action  stage 
and  should  not  occur.  The  variables  of  Communication,  Docu¬ 
mentation,  and  User  all  exhibit  the  same  impact  on  the  man¬ 
agement  system.  The  impact  of  these  initial  factors’  degrada¬ 
tion  on  the  management  system  is  similar  to  that  of  the 
Executive  Steering  Committee.  Any  degradation  in  these 
initial  factors  benefits  the  Screening  Panel  at  the  expense 
of  the  Corrective  Action  function.  Degradation  of  the  ini¬ 
tial  factors  of  Executive  Steering  Committee,  Design,  Commun¬ 
ication,  Documentation,  and  User  should  be  avoided  due  to 
the  exponential  impact  experienced  by  the  management  system 
subsequent  to  the  Screening  Panel  stage. 

There  is  only  one  initial  factor  that  does  not  affect 
the  Configuration  Sub-board,  Maintainability.  All  of  the 
remainder  exhibit  an  exponential  increase  in  the  level  of 
activity  for  the  Configuration  Sub-board.  A  variable  that 
exhibited  a  geometric  decrease  in  the  level  of  activity  from 
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an  initial  exponential  increase  would  support  the  determina¬ 
tion  that  the  variables  exhibiting  this  characteristic  ar^ 
asymptotic.  Such  variables  are:  Executive  Steering  Committee, 
Design,  Documentation,  Management,  and  User.  Although  deg¬ 
radation  of  these  variables  is  bounded  by  the  asymptote,  any 
degradation  of  these  variables  results  in  conditions  in  the 
later  stages  of  the  management  system  that  are  detrimen¬ 
tal  to  the  system.  The  initial  factors  of  Plan,  Control, 
Responsiveness,  Communication,  and  Personnel  all  exhibited 
an  exponential  increase  that  remained  constant  with  con¬ 
tinued  degradation  of  the  variable.  This  indicates  that 
there  is  a  critical  point  in  the  degradation  of  these  varia¬ 
bles  beyond  which  no  further  impact  on  the  Configuration 
Sub-board  will  be  experienced.  For  the  initial  factors  of 
Test  and  Requirements,  no  degradation  of  these  management 
principles  is  practical.  Both  resulted  in  continued  expo¬ 
nential  or  geometric  increases  in  the  level  of  activity  for 
the  Configuration  Sub-board  for  subsequent  degradations. 

Based  on  the  impact  of  these  variables,  Test  and  Requirements, 
to  the  Configuration  Sub-board,  both  must  not  be  allowed 
to  deviate  unroonitored. 

All  of  the  initial  factors  resulted  in  an  exponential 
growth  in  the  level  of  activity  for  Corrective  Action.  The 
principles  of  Test,  Executive  Steering  Committee,  Requirements, 
Design,  and  Management  can  experience  no  degradation  due  to 
the  impact  that  further  degradations  have  in  terms  of  con¬ 
tinual  exponential  or  geometric  increase  in  the  level  of 
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activity  for  Corrective  Action.  The  principles  of  Maintain¬ 
ability,  Control,  Plan,  Responsiveness,  Communication,  and 
Personnel  indicate  a  constant  exponential  increase  regard¬ 
less  of  the  degradation  of  the  variable.  This  would  indicate 
that  there  exists  a  value  at  which  further  degradation  of  the 
variable  has  no  impact.  The  initial  factor  of  Documentation 
has  an  asymptotic  relationship  to  Corrective  Action's  level 
of  activity. 

The  initial  factors  of  Test,  Executive  Steering  Commit¬ 
tee,  Requirements,  Design,  Management  and  User  have  an  ex¬ 
ponential  increase  relationship  with  the  Configuration  Con¬ 
trol  Board's  level  of  activity.  The  remainder  of  the  soft¬ 
ware  management  principles  indicate  an  exponential  increase 
that  does  not  vary  with  further  degradation  of  the  variable. 

For  Software  Release,  the  variable  of  Test,  Executive 
Steering  Committee,  Requirements,  Management,  and  User  are 
critical  and  no  degradation  of  these  variables  can  be  exper¬ 
ienced  without  increasing  the  exponential  increase  in  this 
level  of  activity.  Design  and  Documentation  exhibit  an 
asymptotic  relationship  to  Software  Release.  The  remainder 
of  the  principles  remained  constant  after  some  critical 
value  had  been  passed  in  the  degradation  of  the  principle. 
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Management  System  Function 
Critical  Exogenous 
Variables 

Based  on  the  impact  to  the  management  system  of  an  ex¬ 
ponential  growth  in  the  level  of  activity  for  that  function 
due  the  degraded  responsiveness  and  control  ability  of  the 
management  system,  a  determination  can  be  made  as  to  whe.i 
compliance  with  an  initial  factor  must  be  assured  in  order 
to  avoid  detrimental  impacts  to  responsiveness  and  control 
from  management  system  function.  During  the  Screening  Panel 
function  the  emphasis  should  be  on  the  requirements  of  the 
Executive  Steering  Committee,  Design,  Communiation ,  Documen¬ 
tation,  and  User.  During  the  Configuration  Sub-board  func¬ 
tion,  the  primary  initial  factors  are  Test  and  Requirements. 
In  addition,  the  initial  factors  of  Plan,  Personnel,  Respon¬ 
siveness,  and  Control  require  verification.  At  the  Correc¬ 
tive  Action  function,  the  initial  factors  of  Management  and 
Maintainability  require  attention.  These  assignments  signify 
that  that  is  where  attention  to  a  particular  initial  factor 
becomes  critical  for  the  management  system.  Table  6  is  a 
ranking  of  the  software  management  principles  based  on  the 
magnitude  of  the  impact  experienced  by  the  management  system 
when  the  appropriate  initial  factor  had  a  value  of  .5.  These 
rankings  coincide  with  the  management  system  determinations 
of  when  an  initial  factor  becomes  critical.  Table  6  pro¬ 
vides  a  priority  guide  as  to  which  initial  factors  should 
receive  attention  at  a  particular  management  system  stage. 


TABLE  6:  RELATIVE  RANK  OF 
EXOGENOUS  VARIABLES 


Interpretation  of  Software 
Management  Principles 
Critical  to  Manage¬ 
ment  System  Function 

The  meaning  of  an  initial  factor's  impact  on  the  man¬ 
agement  system  can  be  interpreted  and  is  based  on  the  require¬ 
ments  of  the  initial  factor's  software  management  principle, 
those  applied  principles  it  affects,  and  the  initial  con¬ 
ditions  of  the  model.  Each  software  management  principle 
will  be  reviewed  with  the  objective  of  identifying  those 
requirements  of  a  principle  that  contributed  to  that  prin¬ 
ciple  becoming  a  critical  management  concern. 

The  User  principle  is  the  most  critical  concern  to  the 
Screening  Panel  function  of  the  management  system.  Based  on 
the  initial  conditions  of  all  exogenous  variables  being  in 
full  compliance,  the  factor  that  is  contributing  to  this 
concern  is  the  initial  User  conditions.  This  can  mean  that 
there  is  only  average  support  input  from  the  Users  for  the 
ECS  support  activity  or  the  users  disagree  with  the  support 
being  provided.  The  resulting  impact  of  the  user  principle 
degradation  at  the  Corrective  Action  function  signifies  the 
importance  of  the  Users  support  and  participation  in  the 
initial  functions  of  a  management  system  for  ECS.  User 
participation  and  support  of  the  management  system  is  funda¬ 
mental  at  this  early  function  of  the  management  system  and 
must  continue  throughout  the  remainder  of  the  management 
system. 
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The  Executive  Steering  Committee  has  the  second  most 
significant  impact  on  the  management  system  at  the  Screening 
Panel.  Since  all  of  the  initial  variables  excluding  the 
Committee  itself  are  initialized  at  full  compliance,  the 
determination  can  be  made  from  the  factors  of  this  principle 
that  the  cause  of  the  impact  is  the  principle  itself.  The 
purpose  of  the  Executive  Steering  Committee  is  to  provide 
goals  for  the  support  organization,  define  responsiveness 
requirements,  and  assure  effective  participants  communica¬ 
tions.  When  there  are  problems  in  this  principle,  it  is 
identifiable  by  management  layering,  communication  problems, 
and  no  User  support.  Since  both  Communication  and  User 
were  initialized  at  full  compliance,  it  can  be  ascertained 
that  the  impact  experienced  by  the  management  system  is  due 
to  the  layering  of  management  between  the  Screening  Panel  and 
the  User.  In  this  model  there  is  only  one  management  layer 
between  the  user  and  the  Screening  Panel,  the  Software 
Engineering  function.  The  impact  of  this  one  management 
layer  on  the  management  system  and  its  later  ramifications 
on  the  Corrective  Action  function  highlights  the  importance 
of  reducing  and  minimizing  various  management  layers.  The 
interface  between  the  Screening  Panel  and  the  Users  is 
critical  and  as  such  should  have  minimal  management  layers 
separating  them.  The  one  management  layer  in  the  model  is 
essential  to  the  Screening  Panel's  ability  to  function  but 


no  other  layers  can  be  allowed.  Even  with  this  required 
management  layer,  the  emphasis  must  be  on  assuring  no  other 
layers  and  no  degradation  of  the  management  system  from  this 
layer . 

The  Design  principle  are  the  concepts  utilized  in  devel¬ 
oping  the  ECS.  It  is  the  design  requirements  and  the  actual 
design  techniques  employed  by  design  personnel  in  the  devel¬ 
opment  effort.  The  impact  to  Design  are  in  terms  of  com¬ 
plexity,  readability,  and  inflexibility  of  the  ECS.  These 
factors  have  a  significant  impact  on  the  personnel  who  will 
perform  the  corrective  actions.  The  significance  of  the 
impact  of  Design  on  the  Screening  Panel  is  that  as  the  com¬ 
plexity  of  the  design  increases,  it  affects  the  ability  of 
the  support  personnel  to  interpret  what  corrective  action  is 
required.  This  in  turn  causes  a  delay  in  the  Screening 
Panel  in  determining  the  appropriate  action  for  a  change. 

This  complexity  of  design  along  with  its  inflexibility  and 
difficulty  in  readability  will  have  a  significant  impact  on 
the  Corrective  Action  function.  The  Design  of  the  ECS  must 
be  kept  as  simple  as  possible  utilizing  structure  and  design 
techniques  that  will  reduce  complexity  of  the  design.  The 
impact  of  Design  on  the  management  system  indicates  the 
necessity  of  standard  Design  requirements  for  ECS  in  order 
to  reduce  the  complexity  inherent  in  independent  design 
efforts. 
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Communication  involves  the  User  and  the  support  organ¬ 
ization  exchanging  information  as  to  condition,  priorities, 
requirements,  and  utility  of  the  ECS.  Although  the  User 
may  be  in  support  of  the  ECS  management  system,  if  his 
requirements  are  not  being  communicated  to  the  support 
organization,  that  support  is  to  no  purpose.  The  degrada¬ 
tion  of  Communication  to  the  Screening  Panel  function  high¬ 
lights  the  importance  of  an  effective  communication  link  with 
not  only  the  Users  of  the  ECS  but  all  other  organizations 
providing  support  or  involved  with  the  ECS.  A  degradation 
of  the  Communication  principle  signifies  that  the  necessary 
requirements  for  the  ECS  are  not  being  conveyed  and 
erroneous  or  unusable  ECS  can  be  provided.  It  also  signifies 
that  the  design  effort  by  the  support  organization  is  being 
done  independent  of  the  organizations  which  specify  the  ECS 
requirements. 

The  Documentation  principle  degradation  and  its  associa¬ 
ted  impact  on  the  management  system  illustrated  the  impor¬ 
tance  of  the  support  organization  being  provided  the  appro¬ 
priate  support  documentation.  This  documentation  includes 
requirements,  maintenance,  and  design  documentation.  Ex¬ 
tensive  research  has  identified  what  documentation  is  neces¬ 
sary  for  a  support  organization  to  function  effectively. 

The  significance  of  this  simulation  was  to  indicate  at  what 
point  in  the  management  system  that  this  required  initial 
documentation  had  a  significant  impact  on  the  management 


system.  The  Screening  Panel  is  this  initial  function  of  the 
management  system  and  any  impact  at  this  point  can  have  only 
an  increasingly  exponential  impact  on  the  management  system. 

The  Configuration  Sub-board  is  the  function  at  which 
the  Requirements  principle  became  critical.  This  is  under¬ 
standable  since  this  is  the  point  at  where  the  decision  must 
be  made  as  to  the  requirements  of  ECS.  Based  on  this  require¬ 
ments  determination,  decisions  are  made  as  to  the  priority 
of  the  required  action,  its  scheduling  requirements,  and 
the  appropriate  action.  These  determinations  cannot  be 
made  independent  of  the  ECS  requirements. 

The  importance  of  the  Test  principle  to  the  Configura¬ 
tion  Sub-board  is  in  terms  of  what  testing  has  been  done, 
what  is  required,  and  who  will  perform  it.  Inadequate  test¬ 
ing  of  ECS  has  a  direct  impact  on  the  reliability  of  the  ECS 
being  provided  to  Users.  Whether  that  testing  is  accomplished 
by  the  support  organization  or  in  conjunction  with  the  Users 
is  not  stipulated.  The  emphasis  is  on  a  determination  of 
what  the  requirements  for  testing  are.  Based  on  these 
determinations,  the  appropriate  decision  can  be  made  to 
assure  the  appropriate  testing  is  accomplished. 

The  degradation  of  the  Planning  principle  means  that 
either  the  specified  palnning  for  ECS  support  is  not  being 
complied  with  or  that  none  exists.  Since  a  management  system 
does  exist,  it  can  be  ascertained  that  the  planning  either 
is  of  poor  quality  or  does  not  have  long  range  objectives, 
or  does  not  address  life-cycle  costs.  This  conclusion  is 
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substantiated  by  the  findings  of  the  simulation  of  the  Warner 
Robins  Air  Logistics  Center's  management  system.  The  em¬ 
phasis  in  that  effort  was  on  compliance  with  the  milestones 
of  the  G026  system  which  were  contrary  to  the  Planning 
principle.  The  objectives  of  planning  at  the  Configuration 
Sub-board  are  in  providing  the  most  efficient  and  economical 
course  of  action  for  a  support  organization's  activity. 

This  can  not  be  done  unless  long-range  strategic  planning 
for  ECS  support  has  been  accomplished. 

Responsiveness  is  the  result  of  the  culmination  of  all 
of  the  software  management  principles  and  is  apparent  at  the 
Configuration  Sub-board.  At  the  Configuration  Sub-board, 
the  primary  concern  is  the  priority  of  the  actions  being 
reviewed.  The  loss  or  replacement  of  the  responsiveness 
requirements  of  the  support  organization  indicates  that  re¬ 
sponsiveness  is  not  important.  As  established  by  both  simu¬ 
lations,  the  result  of  the  replacement  or  loss  of  respon¬ 
siveness  is  extension  of  the  corrective  action  time. 

The  Control  principle's  objective  is  to  assure  that  the 
support  for  ECS  is  responsive  and  that  the  correct  ECS  con¬ 
tent  and  capability  is  being  provided  to  the  ECS  users. 

Those  determinations  are  initially  made  at  the  Configuration 
Sub-board.  Degradation  of  the  control  function  can  either 
be  from  erroneous  updates  to  the  ECS  by  personnel  or  from 
Users  taking  corrective  action  as  a  result  of  unresponsive 
support  organizations. 
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The  ease  of  maintenance  that  is  built  into  ECS  initially 
•  *  •  .  #  »  . 

and  subsequently  in  corrective  actions  determines  the  ability 
to  perform  corrective  action.  As  maintainability  of  ECS 
decreases,  the  ability  of  personnel  to  perform  the  required 
corrective  action  is  impaired.  As  a  result  of  any  corrective 
action,  the  maintainability  of  the  ECS  is  affected  by  the 
degree  to  which  the  corrective  action  changed  and  affected 
the  ECS.  The  desired  level  of  maintainability  required  to 
support  ECS  must  be  present  before  and  after  any  corrective 
action.  Maintainability  has  a  significant  impact  on  the 
management  system  at  the  Corrective  Action  function  due  to 
the  fundamental  nature  of  that  activity. 

The  Management  principle  is  concerned  with  the  optimal 
allocation  of  corrective  actions,  ECS’s  integrity,  and  ECS's 
operability.  These  elements  are  directly  affected  at  the 
Corrective  Action  function  of  a  management  system.  Due  to 
the  inherent  flexibility  of  software,  tradeoffs  can  be  nego¬ 
tiated  on  whether  or  not  a  certain  software  change  should  be 
accomplished.  The  main  concern  in  this  instance  is  in  what 
benefits  can  be  derived  from  the  system  if  the  ECS  is  changed 
in  a  way  that  is  sub-optimal  without  adverse  affects.  Al¬ 
though  the  management  principle  is  not  as  critical  as  the 
other  principles  in  the  management  system,  Management  does 
have  an  exponential  impact  on  the  management  system. 
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Management  Systems  Princi¬ 
ples  Application 
Analysis 

Each  software  management  principle  has  a  fundamental 
role  in  assuring  responsiveness  and  configuration  control 
in  the  ECS  management  system.  The  importance  of  each  prin¬ 
ciple  is  tied  to  the  activities  of  that  function  in  the  man¬ 
agement  system  to  which  it  is  most  directly  related.  The 
application  of  the  software  management  principles  in  the 
NASA  and  in  the  Tactical  management  systems  directly  con¬ 
tribute  to  the  ability  of  these  two  organizations  to  pro¬ 
vide  responsive  support.  Conversely,  the  lack  of  the  soft¬ 
ware  management  principles  application  in  the  Warner  Robins 
management  system  directly  contributes  to  the  inability  of 
this  management  system  to  be  responsive.  The  difference 
in  responsiveness  magnitudes  is  dependent  on  the  adherence 
to  sfotware  management  principles. 

National  Aeronautics  and 
Space  Administration 
Space  Shuttle  Mass 
Memory  Management 
System 

The  management  philosophy  for  the  Orbiter  Avionics  Soft¬ 
ware  Control  Board  (OASCB) ,  the  single  point  of  control  for 
the  Space  Shuttle's  Mass  Memory  software,  is  directed  towards 
assuring  correct  configuration  of  all  software  within  the 
Orbiter  Avionics  System,  including  Mass  Memory  Units,  during 
all  vehicle  and  test  operations.  In  order  to  accomplish  this 
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responsibility,  the  OASCB  has  defined  the  procedures  and  re¬ 
sponsibilities  used  to  assure  the  correct  content  and  mainten¬ 
ance  of  avionics  computer  memories  and  mass  memory  units 
tapes. 

The  responsiveness  requirements  of  maintaining  the  capa¬ 
bility  and  concern  to  make  rapid  changes  is  accomplished  by 
collocating  personnel  at  the  various  sites  utilizing  the 
software.  These  collocated  groups,  IBM  Test  &  Operations 
(T&O) ,  are  given  specific  tasks  to  assure  that  software 
released  to  a  site  is  being  utilized  properly,  that  known 
problems  and  changes  are  recognized  and  considered,  that 
work-around  procedures  that  have  been  previously  approved 
are  utilized  procedures  that  have  been  previously  approved 
are  utilized  when  required,  that  installation  of  the  software 
is  proper,  and  that  no  programming  or  alterations  takes 
place  without  prior  approval  from  the  OASCB.  In  addition 
to  providing  this  utilization  support,  these  collocated  groups 
provide  on-site  support  on  a  24-hour  basis  and  monitor  all 
activities  involving  the  software.  In  the  event  a  new 
requirement  or  problem  is  generated,  this  group  assures  the 
validity  of  the  action,  verifies  that  it  is  not  a  unique 
occurrence,  gathers  as  much  relevant  data  as  possible  for 
diagnosis  of  cause,  and  reports  all  actions  whether  unique 
or  repeatable,  problem  or  requirement  to  the  Test  and  Opera¬ 
tions  Board  of  the  impacted  subprogram  within  24  hours. 

Most  importantly,  this  group  negotiates  between  the  users 
and  its  Test  and  Operations  Board  the  priority  of  a  required 
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action,  its  need  date,  and  its  relative  importance  to  other 
actions  existing  or  incoming.  This  evaluation  of  priority 
is  accomplished  daily  with  all  new  and  old  actions  not  in 
work  reevaluated  for  priority.  The  timeliness  requirement 
agreed  to  by  this  process  is  the  deciding  factor  in  the 
providing  of  logistics  support  for  a  particular  action. 

In  line  with  its  responsibility  of  assuring  that  the 
correct  software  content  is  available,  the  OASCB  exercises 
total  control  over  all  software  released  and  its  documenta¬ 
tion.  For  those  changes  accomplished  on  an  emergency  basis, 
approval  by  the  OASCB  is  mandatory  within  24-hours  or  the 
change  must  be  removed  from  the  software.  Only  those 
changes  specifically  approved  by  the  OASCB  are  built  into 
a  new  tape  release  and  only  those  tapes  expressly  approved, 
via  the  OASCB  release  documentation,  are  released  for  utili¬ 
zation  by  users.  In  order  that  the  OASCB  will  not  impact 
responsiveness,  the  OASCB  meets  on  a  daily  basis  with  tele¬ 
phone  and  emergency  meetings  held  on  an  as-required  basis. 
Since  the  main  purpose  of  the  OASCB  is  operational  software, 
its  management  philosophy  is  common  with  that  of  the  users. 

The  requirements  of  software  integrity,  supportability,  opera¬ 
bility,  and  timeliness  has  been  specifically  delegated  to  the 
responsible  development  organizations'  Test  and  Operations 
(TCO)  Board.  The  T&O  Boards  are  authorized  to  develop 
changes  compatible  with  the  OASCB  approved  requirements  and 
cannot  release  their  software  until  approved  and  processed  by 


the  OASCB .  The  emphasis  of  these  T&O  Boards  is  to  provide 
the  required  software  as  needed.  The  OASCB  is  responsible 
for  assuring  interfaces,  operability,  compatibility,  and 
integrity  of  software  released  to  users. 

The  required  communication  is  implemented  by  integrating 
all  activities  with  affected  organizations  as  much  as  pos¬ 
sible.  The  collocated  groups  are  part  of  a  specific  Test 
and  Operation  Board  and  as  such  perform  important  liason 
functions  as  coordinating  schedules,  assessing  priorities, 
reporting  problems  and  performing  release  coordination 
(release)  with  the  users,  the  Test  and  Operations  Board,  and 
the  OASCB  release  organization.  The  Test  and  Operations 
Boards  maintain  effective  communication  with  all  users  and 
affected  organizations  by  providing  membership  on  their 
board  for  representatives  from  each  affected  organization. 

The  OASCB  release  organization,  the  Mass  Memory  Release 
Coordination  Team,  is  that  organization  that  is  specifically 
charged  by  the  OASCB  to  develop  and  implement  all  aspects  of 
logistics  support  for  all  software  releases  and  actions. 

This  team  involves  all  members  of  the  OASCB,  each  Test  and 
Operations  Board,  all  users,  and  contractors.  The  objective 
of  this  group  is  to  assure  that  the  required  software  release 
with  the  appropriate  changes  are  available  to  the  users  as 
negotiated  and  as  approved  by  the  OASCB.  Consequently,  to 
assure  that  the  proper  communication  is  being  made,  specific 
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individuals  of  each  applicable  organization  are  named  as 
contact  points  and  charged  with  the  responsibility  of  its 
organization  for  the  team. 

In  order  to  assure  that  the  management  responsibilities 
are  clearly  delineated  and  controlled,  each  organization  has 
developed  a  specific  plan  detailing  its  responsibility  and 
limitations.  These  documents  are  controlled  by  the  OASCB. 
The  emphasis  is  on  the  delegation  of  the  management  respon¬ 
sibility  to  that  level  that  was  involved  in  the  actual 
development  of  the  software,  its  requirements,  and  the 
interfaces  associated  with  those  requirements.  Specific 
requirements,  interfaces,  development  specifications,  and 
other  documentation  utilized  in  the  development  activity 
are  maintained  current  and  are  enforced  by  the  OASCB. 

The  design  of  the  mass  memory  program  involves  ten 
separate  subprograms  which  are  comprised  of  further  sub¬ 
programs.  All  aspects  of  the  programming  effort  are  con¬ 
trolled  and  documented,  i.e.,  tape  storage  space  allocation, 
type  tracked  tapes,  and  data  location  on  tapes.  Each 
corrective  action  or  change  to  a  program  is  controlled  by 
documentation,  by  a  quality  control  center,  and  by  maximiz¬ 
ing  utilization  of  design  personnel. 

In  recognition  of  the  need  for  changes  and  updates  to 
delivered  software,  specific  categories  of  changes  have  been 
identified  to  facilitate  planning  of  when  a  user  can  expect 
a  change.  There  are  four  classes  of  changes  depending  on 


the  amount  of  compilation  required  by  the  release.  Each 
major  release  has  a  documented  release  date  (two  month  in¬ 
terval)  and  is  specifically  controlled  as  to  content,  scope 
and  need.  In  addition,  plans  have  been  developed  to  assure 
responsiveness  and  control  considerations  by  providing  up¬ 
date  releases  as  required. 

Documentation  requirements  are  enforced  by  utilizing 
an  Integration  Plan  whichprovides  specific  documentation 
requirements  for  each  release.  These  requirements  are  de¬ 
lineated  in  the  plan  and  each  using  activity  is  given  an 
opportunity  to  specify  the  type  and  extent  of  documentation 
it  requires  for  a  specific  release.  The  version  release 
documentation  accompanying  a  release  is  explicit  in  speci¬ 
fying  the  contents  of  a  release,  its  utility,  authorization 
and  impact  on  the  master  tape.  All  documentation  utilized 
in  the  development  activity  is  maintained  current  and  is 
required  delivery  to  the  users  with  each  major  release  of 
software.  This  documentation  is  available  to  the  users  to 
facilitate  the  utilization  of  the  software. 

The  requirements  for  the  Mass  Memory  programs  were 
developed  in  conjunction  with  the  users  and  those  organiza¬ 
tions  specifically  charged  with  that  development  respon¬ 
sibility.  The  involvement  of  the  users  is  stressed  in  the 
development  process,  throughout  the  implementation  process, 
and  in  any  changes  that  may  be  required  for  that  software 
after  development. 
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The  users  are  totally  involved  in  all  aspects  of  the 
management  system.  They  participate  as  members  of  all 
control  boards  and  in  all  working  groups.  Specific  respon¬ 
sibilities  are  assigned  to  the  users  as  to  the  application 
of  the  software,  its  function,  and  its  utility  in  the  users' 
environment. 

Testing  in  this  management  system  is  mainly  conducted 
concurrently  with  utilization.  Except  for  testing  performed 
by  a  Test  and  Operations  Board  to  assure  a  program's 
integrity,  operability,  and  performance,  the  main  part  of 
the  testing  is  done  after  the  software  is  put  into  use. 

The  Executive  Steering  Committee  for  this  management 
system  is  the  OASCB.  Their  management  philosophy  has 
assured  that  there  exists  minimal  management  layering, 
that  priority  problems  are  addressed  and  that  effective 
communication  between  all  involved  organizations  is  assured. 

The  ability  of  the  OASCB  to  provide  the  degree  of 
responsiveness  and  control  in  this  management  system  is  due 
in  large  part  to  the  fact  that  the  majority  of  its  activi¬ 
ties  and  personnel  are  a  contractor  performed  function.  As 
such,  this  alleviates  the  OASCB  of  problems  associated  with 
personnel  considerations.  The  ability  to  provide  24-hour 
response  capability  is  directly  due  to  this  fact. 
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Tactical  Air  Force  Com¬ 
mand,  Control  and 
Intelligence  Soft¬ 
ware  and  Management 
System 

The  philosophy  used  by  the  Tactical  Air  Force  in  its 
management  system  is  to  assure  the  compatibility  and  inter¬ 
operability  of  current  and  future  tactical  Command,  Control, 
and  Intelligence  systems.  Extensive  discussion  of  some  of 
the  management  principles  is  not  possible  due  to  the  security 
classification  of  the  appropriate  documentation. 

In  terms  of  responsiveness,  the  main  consideration  is 
the  alleviation  of  the  problem  or  implementation  of  a  re¬ 
quirement  but  not  at  the  expense  of  the  Command,  Control  and 
Intelligence  system  that  has  been  certified  for  use  in 
multiple  theaters  of  operation.  As  such,  the  concern  is  to 
provide  the  most  expeditious  resolution  of  a  change,  whether 
problem  or  requirement,  and  to  verify  that  change  exten¬ 
sively  prior  to  utilization  in  order  to  restore  operational 
readiness  as  rapidly  as  possible.  The  tradeoff  in  respon¬ 
siveness  and  control  is  on  a  degraded  system  versus  a  system 
that  is  made  inoperable  due  to  implementation  of  a  change 
without  adequate  testing  and  validation.  Utilization  of  an 
uncertified  change  is  limited  to  those  areas  where  the 
Command,  and  Control,  and  Intelligence  system  has  not  been 
certified.  In  this  context,  turnaround  of  a  problem  or 
change  is  rapid  but  authorization  for  use  in  the  Command, 
Control,  and  Intelligence  system  is  limited.  Consequently, 
testing  of  a  change  is  much  more  extensive  than  normally 
performed. 
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Control  is  maintained  through  the  Tactical  Air  Force 
Configuration  Management  Board  (TAF  CMB) .  All  actions  that 
affect  a  Command,  Control,  and  Intelligence  system  require 
authorization  by  this  board  prior  to  implementation  in  a 
system  that  has  been  certified  by  this  board.  As  such  all 
aspects  of  the  management  system  are  specifically  controlled 
by  the  board,  i.e.,  interfaces,  problem  reporting,  proce¬ 
dures,  system  description,  standards,  change  procedures, 
and  message  standards. 

In  order  to  facilitate  communication,  specific  stan¬ 
dards  have  been  established  controlling  all  aspects  of  com¬ 
munication  between  organizations.  Each  organization  involved 
in  the  resolution  activity  has  specific  requirements  to  pro¬ 
vide,  develop,  or  communicate  information  to  those  other 
activities  involved.  The  organization  responsible  for  reso¬ 
lution  of  a  problem  is  provided  direct  interface  with  users. 
This  direct  interface  is  accomplished  by  the  Computer  Pro¬ 
gram  Configuration  Sub-Board  (CPCSB) .  It  is  these  boards 
responsibility  to  validate  a  problem,  determine  its  opera¬ 
tional,  support,  and  utility  impact,  verify  interface  impact, 
and  develop  a  corrective  action.  Communication  in  this 
instance  is  facil-cated  by  the  fact  that  the  members  of  the 
ooards  are  all  users  of  the  software  and  as  such  have  a 
commonality  of  interest  in  the  resolution  of  the  problems. 

The  management  functions  of  assuring  the  optimal  alloca- 
'  >i  the  corrective  action  and  the  associated  ramifica- 
che  system  affected  is  performed  by  the  extensive 


testing  required  on  all  changes  prior  to  implementation  and 
certification.  Of  the  activities  devoted  to  resolution  of 
a  problem,  a  major  portion  is  devoted  expressly  to  testing 
a  change  and  assuring  that  it  does  not  impact  an  established 
interface,  is  allocated  appropriately,  that  corollary  im¬ 
pacts  are  nonexistent,  and  that  the  system's  integrity  and 
operability  is  maintained.  In  order  to  accomplish  this 
activity,  an  extensive  delineation  of  responsibilities  for 
the  various  organizations  involved  has  been  developed  to 
assure  all  aspects  of  the  testing  operation  are  performed, 
verified,  reviewed,  and  evaluated.  Each  of  these  organiza¬ 
tions  has  specific  responsibilities  in  assuring  the  validity 
of  a  change  and  its  correctness. 

The  design  problems  normally  associated  in  the  military 
environment  with  the  transfer  of  software  from  a  contractor 
development  organization  to  the  military  are  avoided  in  this 
management  system.  This  is  because  the  software  is  developed 
in-house  utilizing  the  software  developed  by  contractors  in 
conjunction  with  in-house  development  activites.  Specific 
organizations  are  assigned  the  responsibility  for  developing 
requirements,  interfaces,  standards,  and  documentation  for 
all  aspects  of  the  design  effort. 

Extensive  planning  does  exist  to  assure  that  the 
required  testing  is  accomplished. 

Since  the  software  is  developed  in-house,  complete  and 
thorough  documentation  of  the  software  is  possible.  Docu¬ 
mentation  normally  lost  in  the  transfer  activity  does  not 


occur  to  this  in-house  development.  The  validity  and  content 
of  the  contractor  provided  documentation  is  not  as  essential 
to  the  maintenance  activity  since  the  software  development 
is  basically  an  in-house  activity  reflecting  the  operational 
requirements  of  the  Tactical  Air  Forces. 

In  the  instance  of  a  Command,  Control,  and  Intelligence 
system,  the  emphasis  is  on  the  interfaces  that  the  system 
must  have  in  order  to  provide  an  operational  environment  for 
the  various  weapons  systems  that  will  interface  with  it. 

As  such  these  interfaces  are  strictly  maintained  and  con¬ 
trolled.  Extensive  effort  is  expended  in  assuring  the 
currency  of  these  interfaces  and  their  universality. 

The  Tactical  Air  Force  is  a  user  function  and  as  such 
has  the  total  involvement  of  all  users.  The  Tactical  Air 
Command  is  the  lead  for  the  operation  of  the  management 
system  but  has  direct  involvement  from  all  organizations 
that  will  interface  with  the  Command,  Control,  and  Intelli¬ 
gence  system. 

Testing  is  the  most  critical  element  of  a  Command,  Con¬ 
trol,  and  Intelligence  system.  Extensive  testing  is  devoted 
to  validating  all  changes  prior  to  implementation.  Upon 
successful  completion  of  all  aspects  of  testing,  the  system 
is  certified  for  use  by  all  interfacing  activities. 

The  Executive  Steering  Committee  is  the  TAF  CMB .  Its 
management  philosophy  is  on  assuring  the  interoperability  and 
compatibility  of  its  baselined  systems.  There  exists  no  man¬ 
agement  layering  between  the  users  and  the  corrective  action 
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personnel,  priority  problems  are  strictly  controlled,  delin¬ 
eated,  and  user  oriented,  and  emphasis  is  placed  on  effective 
communication  of  thsoe  changes  required  and  those  authorized 
for  use.  The  total  orientation  of  this  group  is  towards 
assuring  compatibility  and  interoperability  of  certified 
Command,  Control,  and  Intelligence  systems. 

The  activities  of  this  management  system  are  personnel 
dependent.  However,  in  order  to  overcome  this  situation, 
unique  identification  of  the  required  personnel  is  being 
performed  (permitted  by  the  career  identification  scheme 
in  the  military)  to  control  human  resources.  Consequently, 
personnel  requirements  are  not  adversely  impacting  the 
management  system. 

Warner  Robins  Air  Logis¬ 
tics  Center  F-15  Avi¬ 
onics  Software  Manage- 
ment  System 

The  management  philosophy  for  providing  responsiveness 
and  configuration  control  for  the  F-15  avionvics  software  is: 

(1)  the  achievement  of  performance,  schedule,  opera¬ 
tional  efficiency,  and  readiness  objectives  for  the  software 
programs  controlled, 

(2)  allow  the  degree  of  program  maintenance,  design, 
and  development  flexibility  coupled  with  the  appropriate 
degree  of  configuration  control, 
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(3)  assure  efficiency  in  changes  considering  neces- 
nity,  cost,  and  timely  implementation, 

(4)  and  assure  uniform  application  of  configuration 
control  requirements. 

Although  the  operational  concern  exists  within  this 
management  system  for  responsiveness  to  users,  the  capability 
to  provide  that  responsiveness  is  not  present  in  the  system 
as  presently  constituted.  This  conclusion  can  be  drawn  from 
three  major  factors  present  in  the  system.  First  is  the 
method  of  classifying  the  various  discrepancies  that  enter 
the  system.  Second  is  the  utilization  of  the  G026  Material 
Improvement  Project  (MIP)  system  which  monitors  and  controls 
all  activities  associated  with  the  processing  of  discrep¬ 
ancies.  Third  is  the  utilization  of  "blocking"  for  all 
changes.  In  the  first  instance,  the  classification  scheme, 
all  discrepancies  that  are  neither  safety  nor  combat  re¬ 
quired  are  classified  as  a  routine  change.  This  classifica¬ 
tion  is  detrimental  when  introduced  into  the  G026  system. 

In  order  to  understand  the  magnitude  of  this  classification 
and  G026  impact  on  responsiveness,  one  needs  to  understand 
that  all  changes  for  mission  requirements,  no  matter  how 
important  or  extensive,  are  classified  as  routine  if  there 
is  no  safety  or  combat  implications.  For  example,  the 
target  box  through  which  a  pilot  views  his  target  could 
be  erroneous  but  since  this  discrepancy  does  not  affect 
safety  and  is  marginally  combat,  this  discrepancy  could  be 
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classified  as  routine.  The  class  of  a  discrepancy  deter¬ 
mines  how  long  it  will  take  to  be  processed  and  thereby 
affects  responsiveness.  Basically,  according  to  the  G026 
system,  a  no  kit  corrective  action  that  involves  safety  is 
allowed  15  days  for  resolution,  one  involving  combat  condi¬ 
tions  is  allowed  60  days,  and  a  routine  change  is  allowed 
120  days.  In  addition  to  these  foregoing  conditions,  the 
practice  of  blocking  changes  as  discussed  in  the  previous 
chapter  compounds  the  response  delay.  The  factors  of 
classes,  G026,  and  blocking  have  a  direct  adverse  affect 
on  the  responsiveness.  The  user  in  this  instance  is  not 
involved  in  the  activities  associated  with  resolution  of  the 
discrepancy  other  than  the  monitoring  of  the  progress  of  the 
logistics  personnel  in  resolution  of  the  discrepancy.  Once 
a  class  is  assigned  to  a  particular  discrepancy,  that  assign¬ 
ment  is  permanent  and  is  not  normally  changed.  Through  each 
station  of  the  processing  requirements  for  a  discrepancy, 
time  allowances  are  associated  with  each  station  which 
directly  adds  to  the  processing  time  and  detracts  from  the 
responsiveness  of  the  system. 

The  centralized  point  for  control  of  all  software 
changes  is  the  Air  Logistics  Center's  Configuration  Control 
Board  (CCB) .  This  board  exercises  control  over  all  changes 
for  software  under  its  control  within  a  specified  cost  amount 
for  a  particular  change.  Changes  exceeding  the  cost  amount 
are  forwarded  to  Headquarters  Air  Logistics  Command  for 
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disposition.  Associated  with  the  CCB  is  the  Computer  Pro¬ 
gram  Configuration  Sub-Board  (CPCSB)  that  is  responsible  for 
verifying  the  need  of  a  change,  performing  an  impact  evalua¬ 
tion,  determining  the  required  action,  and  providing  a  recom¬ 
mendation  to  the  CCB.  Before,  between,  and  after  these  two 
boards  are  various  other  groups  that  must  review,  document, 
and  process  the  change.  Each  of  these  groups  has  a  G026 
time  allowance  associated  with  its  activity.  This  process 
is  exclusive  of  any  users.  The  actual  control  aspects  for 
the  software  is  focused  in  the  Engineering  Resources  Branch 
located  in  the  Engineering  Division  of  a  Center.  This 
group  is  assigned  the  responsibility  of  verifying  the  valid¬ 
ity  of  the  change,  providing  a  recommended  corrective  action, 
and  after  approval  initiating  corrective  action.  At  the 
time  of  CCB  approval,  there  has  been  no  authorized  effort 
expended  in  performing  a  change.  This  effort  is  initiated 
subsequent  to  the  CCB  approval.  After  corrective  action  has 
been  completed,  the  CPCSB  again  reviews  the  action  prior  to 
release.  The  processing  requirements  of  the  management 
system  are  extensively  documented  with  each  in  compliance 
with  a  higher  management  level  requirements  document. 

There  exists  minimal  communication  between  the  users 
and  the  logistics  personnel  performing  a  particular  correc¬ 
tive  action.  The  users  are  not  involved  in  the  deliberations 
of  the  CCB  or  of  the  CPCSB.  In  fact,  there  is  no  mention  of 
the  users  participating  in  any  of  the  functions  associated 
with  the  corrective  action.  There  do  exist  extensive 
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processing  steps  and  levels  of  management  between  the 
initial  submittal  of  a  discrepancy  and  the  function  that 
determines  the  recommended  corrective  action.  The  commun¬ 
ication  between  these  functions  is  performed  primarily  by 
mail.  Work  on  a  discrepancy  does  not  initiate  officially 
until  a  formal  request  for  a  support  (letter)  is  submitted 
to  the  Engineering  Division.  Determination  of  the  required 
action  for  a  discrepancy  or  the  intent  of  the  users  in  sub¬ 
mitting  a  discrepancy  is  exclusive  of  the  users.  In  the 
event  that  a  discrepancy  involves  or  requires  action  by 
another  Air  Logistics  Center,  the  entire  process  has  to  be 
repeated.  For  joint  efforts  with  another  Center,  the 
activities  at  each  of  the  centers  are  independent  of  the 
other  and  correspondence  is  primarily  by  mail. 

The  management  functions  of  optimally  located  changes, 
effective  maintenance,  verification  of  corollary  impacts, 
integrity,  and  operability  are  the  responsibility  of  the 
Computer  Resources  Branch  of  the  Engineering  Division  in  a 
Center  to  the  extent  of  its  assigned  responsibility.  The 
total  responsibility  for  a  system  may  or  may  not  be  assigned 
to  a  single  Center  or  division  in  a  Center.  Portions  of  a 
system  that  are  the  responsibility  of  other  Centers  or 
other  divisions  in  a  Center  are  not  integrated  in  an  over¬ 
all  total  effort.  Within  the  scope  of  its  assigned  respon¬ 
sibilities,  the  Computer  Resources  Branch  is  responsible  for 
the  total  management  of  the  software. 
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The  design  of  the  software  received  by  the  Center  for 
management  is  the  result  of  the  development  effort  by  a  con 
tractor  responding  to  the  requirements  of  a  different  pro¬ 
curing  organization  and  philosophy.  There  does  not  exist 
any  requirement  for  a  specific  language,  structure,  or  mod¬ 
ularization  in  the  design  effort.  There  is  no  specific 
requirement  on  the  extent  of  documentation  required  for  the 
logistics  effort  other  than  top  level  specification  require 
ments.  There  are  no  requirements  for  traceability  of  the 
contractor's  development  efforts,  corrective  actions,  or 
special  actions  taken  in  developing  the  software. 

Planning  for  the  management  of  the  software  can  be 
summarized  as  (1)  planning  to  assure  the  management  system 
is  in  compliance  with  G026  requirements  and  (2)  planning 
a  management  system  which  utilizes  the  blocking  concept  to 
the  maximum  extent.  Of  the  two,  blocking  is  the  most  dis¬ 
ruptive,  with  time  requirements  for  performing  changes 
being  expanded  in  order  to  perform  all  actions  required  for 
the  entire  block  of  changes.  For  example,  Sacramento  Air 
Logistics  Center  originally  initiated  a  program  of  blocking 
to  produce  changes  in  a  twelve  month  cycle,  then  went  to  a 
fifteen  month  cycle,  and  now  is  considering  extending  to  a 
eighteen  month  cycle.  (A  cycle  is  the  time  required  to  get 
a  change  to  the  user  subsequent  to  its  identification  for  a 
particular  change  block.) 


Documentation  within  the  Air  Logistics  Center  environ¬ 
ment  is  totally  dependent  on  that  data  acquired  by  the 
procuring  organization.  Historically,  the  communication 
link  between  the  centers  and  the  procuring  organizations  has 
been  weak  and  as  such  insufficient  documentation  is  acquired. 

Requirements  are  generated  totally  on  the  information 
received  in  the  initial  communication  of  a  discrepancy. 

The  users  are  marginally  involved  in  the  requirements 
process  if  at  all. 

Users  are  not  on  any  control  board,  are  not  involved  in 
any  corrective  action,  and  have  no  responsibilities  for  a 
discrepancy  once  received  by  a  Center.  The  users  agreement 
or  concurrency  on  a  change  is  not  solicited  other  than  to 
formally  concur  in  the  manhours  required  in  the  field  imple¬ 
mentation  of  the  change. 

The  testing  requirements  for  changes  released  by  a 
Center  are  extensive  and  have  resulted  in  increased  block 
change  time  requirements.  However,  when  a  change  is  released 
by  a  Center  that  change  enters  verification  testing  by  the 
users  prior  to  utilization.  Whether  this  testing  by  users 
is  a  result  of  the  lack  of  user  involvement  in  the  corrective 
process  or  distrust  of  the  center's  ability  is  unknown. 
However,  its  occurrence  questions  the  need  for  extensive 
testing  by  the  Center  and  the  need  for  involvement  of  users 
in  the  change  process. 
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The  Executive  Steering  Committee  for  the  AFLC  manage¬ 
ment  system  is  the  Air  Force  Logistics  Command  Headquarters 
Logistics  Operation  Division.  This  is  based  on  the  fact  that 
all  actions,  requirements,  and  procedures  initiated  by  a 
Center  are  in  response  to  specific  requirements  and  direc¬ 
tions  levied  by  this  division.  Due  to  the  presence  of  com¬ 
munication  problems,  priority  problems,  and  extensive  man¬ 
agement  layering  in  the  AFLC  management  system  it  can  be 
summarized  that  this  division  is  either  unable  or  unwilling 
to  perform  its  function.  It  appears  that  its  management 
philosophy  as  implemented  is  diametrically  opposed  to  pro¬ 
viding  software  that  is  responsive  to  users  requirements 
and  appropriately  controlled. 

Personnel  is  a  critical  factor  in  the  Centers  due  to 
the  inability  to  maintain  qualified,  capable,  and  experi¬ 
enced  personnel.  These  problems  are  due  in  part  to  the 
management  system  and  its  unresponsiveness  and  extensive 
control  requirements.  Another  major  cause  is  the  availa¬ 
bility  of  highly  lucrative  and  rewarding  positions  external 
to  the  government  environment. 

Software  Management  Principles 
Conclusions 

The  Air  Force  Logistics  Command's  management  system  as 
typified  in  the  Warner  Robins  Air  Logistics  Center  manage¬ 
ment  system  is  not  capable  of  providing  ECS  support  to  Users 
in  a  responsive  manner.  The  system  is  capable  of  providing 
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support  but  at  the  expense  of  timeliness  and  lengthening 
corrective  action  time.  In  order  to  provide  support  that  is 
responsive  to  Users  and  ECS  that  has  the  appropriate  degree 
of  control  required  of  its  content,  the  following  changes  to 
the  management  system  must  be  made. 

The  management  system's  orientation  must  be  directed 
towards  responsiveness  to  User  requirements  in  the  opera¬ 
tional  environment  for  the  ECS.  The  Users  must  be  speci¬ 
fically  involved  in  the  formulation  of  those  requirements 
and  in  the  modification  of  the  ECS  when  it  is  not  in  com¬ 
pliance  with  those  requirements.  The  Design  requirements 
for  the  ECS  must  take  priority  over  the  existing  code  of 
the  ECS.  The  guideline  used  for  determining  actions  required 
must  be  dictated  by  negotiation  between  the  software  support 
organization  and  the  Users.  A  management  information  system 
(G026)  must  not  be  a  factor  in  determining  the  timeline 
requirements  for  corrective  actions.  In  particular,  the 
timeline  requirements  as  specified  in  the  G026  system  must 
be  deleted  as  applicable  to  ECS.  These  timeline  requirements 
must  be  negotiated  and  established  by  the  Screening  Panel 
at  its  meetings. 

Blocking  of  changes  must  be  a  function  of  the  require¬ 
ments  of  each  individual  change  and  not  conversely.  Block¬ 
ing  of  changes  is  required  by  the  support  organization  to 
provide  economical  and  efficient  support  in  its  operations. 
However,  the  block  in  which  a  change  will  be  accomplished 


must  be  negotiated  at  the  Screening  Panel  utilizing  the 
required  need  for  the  change  by  the  Users,  other  existing 
required  corrective  actions,  and  scheduling  requirements. 
Blocking  considerations  must  not  dictate  the  time  for  cor¬ 
rective  action  accomplishment.  If  done,  this  will  subse¬ 
quently  impact  the  corrective  action  time. 

The  G026  information  management  system  must  be  respon¬ 
sive  to  the  management  system's  planning  decisions  and  not 
conversely.  The  functions  associated  with  this  information 
management  system  must  operate  in  parallel  with  the  basic 
functions  of  the  management  system  or  not  exist  at  all. 

The  timeline  requirements  of  the  G026  system  must  be  deleted 
with  the  individual  time  actions  required  for  a  change  de¬ 
cided  by  the  Screening  Panel. 

There  must  exist  direct  real-time  communication  inter¬ 
faces  between  Users,  the  Software  Engineering  function,  the 
Computer  Program  Screening  Panel,  the  Computer  Program 
Configuration  Sub-board,  the  Configuration  Control  Board, 
and  the  Software  Release  function.  No  function  must  be 
inserted  between  any  of  these  functions  in  a  support,  com¬ 
munication,  or  any  other  type  role.  Minimal  management 
layering  is  necessary  to  reduce  the  impact  experienced  by 
the  management  system  from  any  other  function  being  intro¬ 
duced  into  the  management  system. 


Headquarters  Air  Force  Logistics  Command  has  the  respon¬ 
sibilities  for  the  Executive  Steering  Committee  function. 

This  Committee  is  fundamental  to  the  success  of  the  manage¬ 
ment  system  for  ECS.  In  addition,  its  diliberations  over 
the  orientation  of  the  management  system  must  be  developed 
in  conjunciton  with  ECS  Users. 

The  Software  Engineering  function  at  an  Air  Logistics 
Center  must  have  direct  interface  with  the  Users  of  the  ECS 
with  problems  and  corrective  action  requests  coming  directly 
to  this  function.  It  is  the  responsibility  of  this  function 
to  determine  the  criticality  of  an  ECS  change.  This  deter¬ 
mination  must  be  done  in  conjunction  with  the  Users  to 
specify  the  requirements  for  each  change.  It  is  also  this 
function's  responsibili ty  to  determine  if  the  required  change 
is  within  the  original  design  requirements  for  the  ECS. 

If  it  is,  the  function  must  provide  a  determination  of  the 
action  required  to  bring  the  ECS  in  compliance  with  the 
requirements.  If  it  constitutes  a  new  requirement,  the 
function  should  determine  the  extent  of  the  requirements, 
its  impact,  and  the  cost  of  performing  the  change. 

The  Computer  Program  Screening  Panel  must  be  comprised 
of  the  System  Manager,  the  Software  Engineering  function, 
and  all  Users.  The  objectives  of  this  group  are  to  determine 
the  priority  of  each  change.  This  group  must  identify  and 
specify  a  plan  detailing  the  corrective  action  for  each 
change.  It  also  must  negotiate  the  extent  of  testing  that 
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must  be  accomplished  by  making  tradeoffs  between  that  to  be 
accomplished  by  AFLC  and  that  to  be  accomplished  by  Users. 
Each  individual  on  the  Screening  Panel  must  have  clearly 
identified  and  delegated  responsibilities  for  establishing 
the  position  of  his  parent  organization.  The  purpose  of 
these  Panels  is  to  perform  all  of  the  logistics  functions 
required  for  each  change  in  coordination  with  the  Users, 
corrective  action  personnel,  the  testing  organization,  and 
the  ECS  manager. 

The  Computer  Program  Configuration  Sub-board's  primary 
function  is  to  provide  approval  for  either  an  in-house  cor¬ 
rective  action,  processing  of  the  change  to  Headquarters 
AFLC  for  approval,  or  initiating  procurement  action.  Based 
on  its  decision,  the  responsible  parties  must  initiate  the 
appropriate  action. 

The  Engineering  Function  is  to  assure  the  operability, 
maintainability,  integrity,  and  suppor tability  of  the  ECS. 

It  also  assures  that  the  requirements  for  each  change  are 
specifically  satisfied  by  the  appropriate  corrective  action. 
It  is  to  work  in  concert  with  the  User  to  assure  that  the 
requirements  for  a  change  are  understood  and  that  the  appro¬ 
priate  action  was  taken.  It  also  is  to  assure  that  the 
proper  documentation  is  prepared  prior  to  release  of  the 
software.  All  of  its  actions  are  dictated  by  the  plan  nego¬ 
tiated  by  the  Screening  Panel  and  approved  by  the  Computer 
Program  Configuration  Sub-board. 


The  Center's  Configuration  Control  Board  formally 
approves  all  software  releases  to  the  Users.  It  is  the 
checkpoint  that  verifies  that  all  of  the  milestones  and 
agreements  of  the  plan  negotiated  by  the  Screening  Panel 
and  approved  by  the  Configuration  Sub-board  have  been  com¬ 
plied  with  as  negotiated. 

The  Release  function  is  that  organization  that  assures 
that  the  software  being  released  complies  with  all  require¬ 
ments  of  the  plan  negotiated  for  the  corrective  action,  that 
the  release  contains  only  those  corrective  actions  specifi¬ 
cally  approved  by  the  Configuration  Control  Board,  and  that 
all  documentation  and  tape  requirements  for  the  release  are 
on  hand  prior  to  the  release. 

In  general,  the  management  system  for  ECS  within  the 
Air  Force  Logistics  Command  can  be  benefitted  by  applying 
the  software  management  principles.  The  flexibility  and 
real-time  capability  of  software  necessitates  a  management 
system  oriented  to  its  environment.  The  adaptation  of  a 
management  system  developed  primarily  for  hardware  items 
will  not  have  the  flexibility,  change  capability,  and  man¬ 
agement  emphasis  that  software  management  system  requires. 


Chapter  V 


SUMMARY  AND  CONCLUSIONS 

The  management  of  Embedded  Computer  Software  is  a  cri¬ 
tical  activity  in  the  future  of  the  Air  Force  Logistics 
Command.  As  more  weapon  systems  have  Embedded  Computer 
Systems,  the  ability  to  provide  responsive  support  and 
effective  support  by  providing  controlled  software  will 
dictate  who  will  have  that  management  responsibility.  The 
management  capability  to  provide  support  that  is  responsive 
and  does  not  adversely  affect  control  is  possible.  The  in¬ 
ability  of  AFLC  to  currently  provide  responsive  support 
highlights  the  need  within  this  organization  to  change  its 
management  system  to  provide  responsiveness.  If  it  does  not 
the  consequences  can  be  grave.  The  management  system  respon 
sibility  for  this  software  will  be  assigned  to  those  organ¬ 
izations  which  can  provide  this  necessary  responsiveness 
support  but  who  may  not  be  able  to  provide  adequate  control. 
Relying  exclusively  on  hardware  is  not  sufficient  to  assure 
the  continued  existence  of  AFLC.  Quality  support  and  respon 
siveness  must  be  forthcoming  for  Embedded  Computer  Software 
systems. 


83 


The  basic  problems  in  the  current  AFLC  management 
system  are  attributable  to  its  utilization  of  proven  hard¬ 
ware  systems  and  its  reluctance  to  provide  a  more  dynamic 
management  system  for  ECS.  The  problems  apparent  in  extend¬ 
ing  corrective  action  times,  unresponsiveness  statements  by 
Users,  and  internal  management  problems  are  due  to  utiliza¬ 
tion  of  antiquated  management  information  systems,  hardware- 
oriented  procedures,  and  limited  responsibility  delegation. 

The  restructureing  of  the  management  system  for  ECS  in 
AFLC  around  the  four  basic  functions  is  possible,  however, 
extensive  documentation  changs  in  terms  of  requirements, 
regulations,  and  operating  instructions  must  be  accomplished 
prior  to  any  formal  change  in  the  management  system. 

The  excuse  used  perennially  in  AFLC  of  inadequate  docu¬ 
mentation,  although  valid,  highlights  the  reluctance  of  this 
organization  to  take  corrective  action.  Extensive  docu¬ 
mentation  and  research  has  been  performed  on  what  software 
documentation  is  required  for  maintenance  activity.  However, 
AFLC  has  not  taken  action  to  initiate  these  corrective  actions 
in  their  operations  even  in  upgrading  its  contractor  Version 
Description  Document  requirements  and  in  Program  Management 
Responsibility  Transfer  planning. 

The  orientation  of  a  management  system  to  user  require¬ 
ments  and  assuring  the  software  is  in  compliance  with  those 
requirements  is  not  an  objective  in  AFLC  currently.  In  order 
to  alter  the  management  system  to  pursue  these  goals,  a  total 
reorientation  of  the  management  system  for  ECS  is  required. 
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The  current  capabilities  in  the  AFLC  management  system 
for  ECS  are  being  experienced  due  to  the  transfer  of  highly 
qualified  personnel  from  external  organizations  (NASA  and 
civilian  contractors).  As  economic  conditions  improve,  or, 
more  likely,  as  the  AFLC  management  situation  finally  reaches 
the  point  where  these  individuals  no  longer  can  cope  with 
the  system,  these  valuable  resources  will  leave. 

Currently,  AFLC  is  pursuing  a  hodgepodge  approach  to 
testing.  Individual  weapon  system  ECS  applications  are 
being  provided  multi-million  dollar  facilities  to  perform 
testing  of  ECS  that  is  being  acquired  with  inadequate  con¬ 
trol  with  minimal  documentation  and  that  will  be  controlled 
by  a  management  system  that  is  totally  inadquate. 

The  recommendation  of  this  paper  is  the  implementation 
of  the  basic  four  functions  within  the  ECS  management  system 
and  providing  to  these  functions  the  management  tools  to 
effectively  perform  their  responsibilities.  Figure  3  is  a 
summary  illustration  of  this  Recommended  Management  System. 
This  figure  identifies  the  various  functions  of  the  manage¬ 
ment  system  and  lists  their  activities  (*) ,  outputs,  parti¬ 
cipants,  and  primary  concerns  in  software  management  princi¬ 
ples  (**)  . 

Additional  research  in  the  activities  of  each  of  these 
functions  is  needed.  Such  research  would  be  beneficial  in 
terms  of  what  actions  are  required,  what  type  of  personnel 
are  required,  and  the  standards  associated  with  their  actions. 
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Of  particular  importance,  is  the  development  of  standards 
for  evaluating  the  performance  of  responsible  Individuals 
and  functions  of  the  management  system.  The  ability  to 
identify  specific  deficiencies  within  the  management  system 
based  on  comparisons  of  performance  to  the  standards  would 
greatly  contribute  to  the  ability  to  modify  the  system  in 
order  to  provide  better  support. 

In  conclusion,  the  basic  principle  of  user  participation 
would  contribute  greatly  to  the  ability  of  AFLC  to  provide 
support  that  is  responsive  and  ECS  that  is  controlled. 
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APPENDIX  A 

RESEARCH  RESPONSIVENESS  AND 
CONFIGURATION  CONTROL 
REQUIREMENTS 
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RESPONSIVENESS 


Responsiveness  encompasses  the  operational  concern  of 
maintaining  the  ability  to  make  rapid  changes  to  ECS  which 
is  impaired  and  that  is  critical  to  the  operational  environ¬ 
ment  (1:12).  The  desired  result  of  an  operational  change 
is  that  the  change  is  accomplished  in  time  to  meet  the 
responsiveness  requirements  of  the  user  and  is  effective 
and  supportable  within  economic  considerations  (1:10). 

The  management  structure  associated  with  ECS  is  the  deter¬ 
mining  factor  in  the  ability  to  provide  the  responsiveness 
required  and  desired.  Responsiveness  is  the  primary 
consideration  of  the  organization  providing  support. 
Responsiveness,  however,  includes  the  principles  of  system 
management,  system  engineering,  system  test,  and  configura¬ 
tion  management  (1:10).  For  the  user  of  ECS,  responsiveness 
considerations  are  the  dominant  criteria  in  any  and  all 
support  decisions.  The  user  evaluates  responsiveness  in 
terms  of  the  "quickness"  of  a  response  to  their  requests 
for  support  (31:139).  The  primary  user  concern  is  that  their 
demands  for  operational  changes  take  priority  over  other 
work  in  process  or  awaiting  action,  such  that  the  change 
has  immediate  attention  and  resolution  (12:156).  This 
necessitates  the  identification  of  the  criticality  of  the 
request,  its  associated  corrective  action,  and  its 


subsequent  release  version  making  the  enhancement  available 
Perennially,  one  of  the  areas  of  friction  between  users  and 
System  Managers  lies  in  this  area.  This  friction  is  that 
users  do  not  get  the  attention  they  want  as  quickly  as  they 
would  like.  Inadequate  response  by  the  System  Management 
function  to  user  needs  invites  the  formation  of  user  teams 
in  the  operational  environment  to  correct  the  problems  that 
it  is  confronted  with.  Therefore,  the  prompt  handling  of 
change  requests  from  users  creates  an  atmosphere  of  credi¬ 
bility  for  the  System  Manager  and  decreases  the  likelihood 
of  the  formation  of  these  user  groups.  The  determination 
of  the  criticality  of  a  change  is  complicated  by  the  fact 
that  troubleshooting  and  problem  isolation  in  a  real-time 
ECS  environment  can  be  extremely  complex.  When  a  real¬ 
time  terminal-oriented  ECS  fails,  the  user  is  immediately 
aware  of  the  problem  and  pressure  immediately  builds  to 
resume  and  restore  the  operational  capability.  Extensive 
research  by  the  Rome  Air  Development  Center  has  shown  that 
repair  time  for  a  software  system  increases  exponentially 
and  is  dependent  on  the  program's  complexity. 

As  previously  stated,  required  responsiveness  is  deter 
mined  by  the  criticality  of  the  change  request  and  must  be 
done  by  an  evaluation  of  actual  priorities  existing  within 
the  support  and  user  organizations.  The  establishing  of 
priorities  for  ECS  change  requests  is  determined  by  what  is 
important  for  the  operation  of  the  weapon  system.  The 
judgement  of  the  criticality  and  the  associated  priority 
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are  based  on  the  actual  change  request  and  ECS  documentation 
(29:71).  The  steps  involved  in  this  evaluation  are  the 
change  request  definition,  priorities  assessment,  and  the 
objective  of  the  change  request  as  determined  by  the  user, 
his  needs,  and  other  existing  change  requests  in  total 
(17:3-110).  This  evaluation  must  be  performed  as  early  as 
possible  in  order  to  specifically  identify  the  operational 
impact  to  the  user  (18:63).  There  must  be  an  established 
method  of  indicating  the  seriousness  of  a  change  request 
with  the  highest  priority  assigned  to  those  requests  with 
the  most  serious  requirements.  Subsequent  to  change  request 
definition  and  priority  assessment,  the  change  request 
requires  scrutiny  for  justification  of  validity,  exhaustive 
ECS  tests  to  determine  associated  problems,  testing  of  the 
release  version,  and  testing  of  the  ECS  with  the  release 
version  incorporated.  Only  versions  that  are  evaluated 
to  be  effective,  reliable,  and  cost  efficient  should  be 
released  (5:34) . 

The  easiest  way  of  providing  the  user  required  respon¬ 
siveness  is  to  allow  the  user  to  accomplish  all  change 
actions.  If  changes  in  this  instance  are  made  without 
effective  change  control  and  documentation,  at  the  very 
least,  the  introduction  of  later  changes  will  be  more  diffi¬ 
cult  and  the  complexity  of  the  program  increased.  When 
users  of  ECS  are  allowed  to  take  corrective  action,  the 
result  is  often  too  rapid  action  in  a  complex  technical 
environment.  These  erroneous  changes  by  users  may  change 
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or  alter  the  original  ECS  design  requirements,  intentionally 
or  unintentionally.  Subsequently,  these  errors  would  have 
critical  implications  for  planned  modifications  or  result 
in  induced  errors  to  the  ECS.  Therefore,  users  are  dis¬ 
couraged  from  malting  corrections  to  ECS.  Often  users 
approach  the  situation  where  a  problem  has  occured  in  a 
crash  project  atmosphere  which  results  in  corrective  action 
that  is  adverse  to  the  software,  the  documentation,  and 
the  overall  management  of  ECS. 

In  an  environment  where  responsiveness  is  important, 
documentation  is  essential  to  determining  the  changes 
required,  when  a  change  request  occurs,  the  needs  of  the 
change  request  and  the  associated  compromises  are  documen¬ 
ted  and  understood  by  both  user  and  System  Manager.  Care 
is  taken  not  to  duplicate  any  previous  work  but  to  capture 
and  utilize  to  the  maximum  extent  lessons  learned  from 
other  ECS  applications.  If  a  change  is  required,  the  change 
is  thoroughly  documented  in  all  documents  and  manuals.  The 
code  is  updated  to  concur  with  the  new  baseline. 

Problems  that  are  designed  into  ECS  are  the  result  of: 

(1)  fuzzy  or  poorly  defined  or  contradictory  requirements, 

(2)  vague  and  overlapping  specification,  (3)  unreadable  and 
hard  to  maintain  specifications,  or  (4)  the  level  of  coding. 
Most  software  change  requests  resulted  from  problems  in 
design  structure  and  system  description  (incorrect,  incom¬ 
plete,  or  unreadable  requirements)  (28:122).  The  amount 

of  time  to  be  spent  by  the  programmer  searching  for  the 
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problem  and  possible  solutions  is  a  function  of  the  com¬ 
plexity  of  the  program  and  the  importance  of  the  problem. 

The  type  of  error  (Appendix  B)  is  subjective  and  can  differ 
from  programmers  in  type,  class,  and  priority.  Even  in  the 
event  corrective  action  is  taken,  absolute  proof  cannot  be 
provided  that  the  error  was  corrected  and  removed  with 
certainty.  Viewing  the  corrective  action  efforts  of  a 
programmer,  the  speed  at  which  he  can  isolate  errors,  deter¬ 
mine  the  required  level  of  corrective  action,  and  take  that 
action  is  a  function  of  ECS  structure,  its  complexity. 

Of  the  various  math  models  advanced  for  predicting  error 
occurrence,  resolution,  and  mean  time  between  failure,  none 
have  been  satisfactorily  proven  to  be  an  effective  predic¬ 
tive  model.  Failures  of  software  in  terms  of  the  time 
required  for  corrective  action  are  in  general  exponential 
in  occurrence,  debugging,  and  recurrence  (33:22).  Existing 
tools  utilized  for  hardware  failure  rates  cannot  be  applied 
reliably  to  software  to  derive  a  failure  rate  (28:122) 
for  basing  required  responsiveness  of  a  support  organization 
These  inabilities  impact  the  ECS  support  organization's 
capability  of  providing  effective  responsiveness  to  the  user 
The  estimating  tools  of  Bayesian  probability  addressing 
errors  existing  in  a  program,  errors  corrected,  and  errors 
attempted  to  be  corrected  provide  the  best  time  require¬ 
ments  for  application  by  a  support  organization  for  determin 
ing  responsiveness  capability  to  an  operational  program 
(11:2)  . 
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CONTROL 


A  well  developed  philosophy  of  ECS  control  establishes 
a  basis  for  effective  responsiveness  and  configuration 
management  for  the  user  and  support  organization.  The 
control  requirements  are  utilized  in  measuring  performance 
of  the  support  organization  in  providing  responsiveness 
and  configuration  control  (31:9).  There  exists  so  ideal 
model  for  prescribing  the  control  features  required  by  a 
large-scale  software  support  operation.  The  extent  of 
configuration  control  is  dictated  by  the  controls  required 
to  insure  that  the  software's  integrity  and  supportability 
is  maintained  (1:18.6).  A  single  point  of  management  is 
established  with  comprehensive  control  over  the  ECS  with 
the  authority  to  allocate  changes  effectively  between 
hardware  and  software  (1:10).  This  single  point  of  manage¬ 
ment  must  have  all  decisions  concurred  in  by  the  users. 

It  should  directly  involve  the  users  in  the  decisionmaking 
process.  The  main  function  of  the  single  point  of  manage¬ 
ment  is  the  defining  and  controlling  of  the  ECS  baseline, 
controlling  all  changes  thereto,  and  assuring  that  hardware 
and  software  match  and  are  in  accordance  with  the  approved 
baseline  (1:10).  This  single  point  of  management  for  ECS 
should  minimize  the  management  by  reaction  process  typical 
of  large  software  operations  (32:3.187). 


The  utilization  of  multilead  or  multi-responsibility 
--control  Gencepts  for.  EC£  either  in ^ the  development  or 
maintenance  of  software  results  in  failure  to  produce  a 
viable  software  product.  Firm  control  of  the  ECS  is  neces¬ 
sary  to  provide  for  change  request  action,  realistic  time 
response  estimates,  minimize  costs,  and  effective  program 
utilization  (10:137).  An  effective  network  of  involved 
organizations ' s  external  and  internal  control  responsibil¬ 
ities  is  an  important  factor  in  the  success  of  an  ECS  and 
should  exist  and  be  applied  throughout  the  life  cycle  of 
the  ECS  (8:61).  The  type  of  control  in  terms  of  accuracy 
and  discipline  requirements  is  jointly  determined  by  the 
System  Manager  and  the  users  of  the  ECS  (9:111).  It  is 
necessary  to  adopt  stringent  management  control  techniques 
to  ensure  that  the  ECS  actions  required  are  performed  and 
the  desired  functions  obtained  as  accurately  as  possible. 
This^ requires  control  over  the  introduction  of  updates  to 
the  ECS  by  insuring  that  the  necessary  control  steps  in 
data  gathering,  collecting,  recording,  transmitting,  pro¬ 
cessing,  storage,  retrieval,  dissemination,  and  usage  have 
been  utilized  (14:2.1).  Associated  with  the  origination  of 
a  revision  to  ECS,  the  proper  controls  must  exist  to  ensure 
the  accurate  and  timely  development  and  distribution  of 
updating  source  documentation  to  existing  documentation 
(30:2.15).  Changes  to  either  the  ECS  or  the  documentation 
must  be  controlled  to  insure  correctness  and  prevent  error. 
The  key  processing  functions  of  the  control  function  must  be 


assigned  to  different  individuals  to  insure  that  unauthorized 
or  erroneous  transactions  cannot  be  entered  into  the  ECS 
without  being  detected  and  prevented  (34:1.109).  These 
individuals  insure  that  specific  tasks  are  accomplished 
efficiently  and  effectively  and  monitor  progress  towards 
resolution  of  a  change  request  within  the  applicable  response 
requirements.  In  order  to  assure  effective  control  between 
these  individuals,  the  interfaces  between  them  must  be 
well  defined  and  managed  with  minimal  time  impact  to  respon¬ 
siveness  and  the  overall  control  being  derived  for  the  ECS 
from  thq  organisations  relationships  withifi  which  these 
individuals  operate  (12:45). 

The  rules  and  procedures  that  dictate  the  type  of 
control  to  be  exercised  is  fundamental  to  the  effective 
initiation  of  change  request  action.  The  essence  of  ECS 
control  lies  in  the  ability  to  apply  measurement  standards 
to  the  quality  of  support  being  provided  within  the  time, 
cost,  and  performance  constraints  dictated  by  responsiveness 
and  configuration  control  (36:4).  However,  standards  of 
control  and  disciplines  required  do  not  usually  exist,  and 
this  impacts  the  ability  to  maintain  ECS  effectively  (35:3.69). 
A  major  problem,  therefore,  is  the  defining  of  standards 
that  can  be  utilized  to  measure  effective  support  (26:3.1). 

In  ECS  control^  the  objective  is  to  centralize  main¬ 
tenance  activities  as  much  as  possible  in  order  to  maximize 
efficiency  while  making  sure  users'  requirements  and  opera¬ 
tions  are  not  impaired  and  to  establish  checks  and  balances 
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between  users'  responsiveness  requirements  and  control 
requirements  of  the  support  organization.  Within  the 
bureaucratic  organizations  present  in  AFLC,  the  demand  for 
control  by  the  System  Manager  frequently  takes  the  form 
of  increasingly  extensive  coordination  requirements  to 
ensure  reliable  behavior  (15:125).  This  form  of  control 
impacts  the  capability  of  providing  the  responsiveness 
required  by  the  user.  The  location  of  an  ECS  System  Manage¬ 
ment  organization  is  dependent  on  ECS  objectives,  the 
organization's  size,  the  available  talent  (personnel),  and 

the  required  geographical  deployment  requirements  of  the 

*  H  -  •  < 

ECS  (12:44).  Decentralization  of  the  ECS  management  respon¬ 
sibility,  as  currently  done  in  the  Air  Force,  insures  that 
users  have  their  applications  defined  and  programmed  by 
personnel  who  are  familiar  with  user  internal  operations 
and  operating  requirements.  The  disadvantage  of  this 
mode  of  operation  is  that  the  user  does  not  consider  all  of 
the  software  and  hardware  ramifications  of  a  change  request 
in  its  resolution  efforts.  Centralization  of  the  ECS 
management  function  within  one  command  has  benefits  in  terms 
of:  more  economy,  greater  control,  more  efficient  utiliza¬ 
tion  of  talent,  greater  coordination  capability,  elimination 
of  duplicative  efforts,  better  integration  of  hardware  and 
software,  and  greater  testing  capability.  Disadvantages 
associated  with  centralized  management  are  user  communica¬ 
tion  problems,  priorities  problems,  and  lack  of  top  manage¬ 
ment  involvement  (3:115).  However,  the  most  effective 


management  method  is  centralization  where  organizations 
performing  similar  functions  can  cooperate  on  change  requests 
without  impacting  quality  of  responsiveness  to  the  user 
(12:44).  A  primary  consideration  in  a  centralization  effort 
is  the  users'  role  and  their  relationship  to  that  organiza¬ 
tion  providing  support.  Another  fundamental  consideration 
is  that  when  input  preparation  work  for  ECS  changes  has 
been  assumed  by  a  central  staff  that  any  unfamiliarity  of 
that  staff  with  the  ECS  requirements  and  needs  should  be 
communicated  to  the  users  and  resolved  with  the  users 
prior  to  implementation. 

COMMUNICATION 

Communication  between  the  user  and  the  ECS  System 
Manager  is  critical  (29:14).  ECS  requirements  should  be 
defined  and  developed  in  close  coordination  with  the  user. 
This  development  is  dependent  on  the  existence  of  good 
communication  between  the  two.  Frictions  that  are  present 
between  the  users  and  the  System  Manager  result  from 
communication  breakdowns.  A  byproduct  of  this  breakdown 
is  ECS  that  is  ineffective  and  behind  schedule  (8:51).  In 
order  to  maintain  the  required  communication,  the  System 
Manager  must  have  the  total  support  operation  sensitive 
toward  and  coordinate  extensively  with  the  user.  The 
initial  information  provided  to  a  maintenance  programmer 
by  a  user  or  a  System  Manager  is  of  great  importance  since 
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erroneous  information  tends  to  be  compounded  and  will  lead 
.to»*emed*iel  <af*for«ts'  that  ar'e  T*ar  from ‘the  actual^hange 
request  (25:50).  The  communication  channel  between  the  user 
and  the  System  Manager  must  be  sifnificant  and  an  important 
feature  between  the  two  organizations  (1:18.6).  The  lines 
of  communication  must  be  short  and  have  great  continuity 
and  awareness  built-in  as  to  reporting  and  responding.  The 
emphasis  must  be  on  a  direct  interface  level  between  the 
System  Manager  and  the  user  with  communication  and  under¬ 
standing  of  requirements  essential.  Attention  must  be 
focused  by  both  the  System  Manager  and  the  user  to  main¬ 
taining  the  rapport  and  coordination  relationship  of  the  '  ’ 
communication  channel  (29:146).  The  System  Manager  must 
have  the  capability  of  interviewing  the  user  to  document 
viewpoints,  needs,  and  concerns  associated  with  ECS.  This 
necessitates  open  communications,  laterally  as  well  as 
vertically,  within  the  System  Management  function  and 
between  it  and  the  ECS  users.  Any  cutoff  or  breakdown 
of  communication  seriously  undermines  the  effectiveness  of 
the  System  Manager  in  regards  to  configuration  control 
and  responsiveness.  A  supportive  relationship  must  exist 
and  assure  the  maximum  effective  communication  is  allowed 
and  that  the  environment  is  conducive  to  information  flow  '*  ’ 
(19:47).  This  means  minimal  management  layering  between 
user  and  the  System  Management  and  the  minimization  of 
extensive  in-house  coordination  requirements.  Communication 


with  the  user  is  a  vital  factor  in  the  effectiveness  of  the 
System  Management  function  and  is  the  make-or-break  factor 
in  responsiveness  and  configuration  control  (8:52).  The 
requirements  for  communication  extends  throughout  the  life 
cycle  of  a  change  request,  initiating  with  required  change 
identification,  through  request  resolution  progress  report¬ 
ing  to  the  useij  and  date  of  resolution  availability,  to 
.resolution  release. 


MANAGEMENT 

The  key  functions  of  the  management  function  is  to 

•  •  *«  •  •  •  •  •  »* 

assure  (1)  that  software  changes  are  optimally  allocated 

to  the  appropriate  system,  (2)  that  effective  maintenance 
of  the  total  weapon  system  is  performed,  (3)  that  potential 
corollary  impacts  from  changes  to  hardware  and  software 
are  identified  and  considered  before  implementation,  and 
(4)  that  the  weapon  system's  integrity  and  operability 
is  maintained  (1:10).  This  places  a  great  inherent  need 
on  the  organizations  involved  with  the  ECS  to  have  their 
responsibilities  delineated  and  defined.  The  degree  of 
responsibility  delineation  and  definition  determines  the 
effectiveness  of  the  ECS  support  effort  and  the  ability  of 
the  organizations  to  mobilize  their  resources  to  respond 
to  a  change  request.  The  management  effort  must  be  directed 
towards  total  technical  directing,  controlling,  and  inte¬ 
grating  of  all  support  efforts  associated  with  the  weapon 
system.  ECS  must  be  managed  as  an  integrated  entity  to 
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insure  the  maximum  flexibility  and  to  insure  responsiveness 
to  user  requirements.  The  System  Management  organization 
must  exist  to  achieve  the  level  of  control  and  responsiveness 
required  by  users.  The  support  organization's  effectiveness 
is  determined  on  the  basis  of  their  achieving  the  level  of 
control  and  responsiveness  required  (15:4).  The  support 
organization's  structure  is  an  influencing  factor  on  the 
ability  of  the  organization  to  perform  effectively.  When 
the  support  organization  has  no  single  focal  point  for  the 
support,  fragmented,  ineffective,  and  inefficient  support 
will  result.  One  of  the  most  important  internal  controls 
within  the  support  organization  is  the  delegation  of  respon- 
sibilities.  Normally,  this  delegation  tends  to  be  informal 
and  vague  (8:28).  Diffused  authority  or  inefficent  dele¬ 
gation  in  such  a  complex  organization  as  is  required  for 
ECS  support  results  in  time  lags  and  delays  impacting 
responsiveness  (21:27).  In  order  to  function  effectively, 
the  management  structure  of  the  organization  must  have 
compatible  functions  within  the  organization  and  external 
to  it  (19:123).  The  skill  in  managing  an  ECS  support 
function  is  the  art  of  matching  the  required  technology 
with  the  precise  needs  of  the  user.  This  requires  a  clear 
delineation  of  the  responsibilities  that  belong  to  the 
users  and  to  the  support  organization  (8:53).  This  respon¬ 
sibility  must  be  clear  cut  in  both  instances  and  is  critical 
to  the  successful  support  operation.  The  responsibility 
delineation  must  describe  in  detail  the  lines  of  authority. 


limitations,  and  associated  ramifications  (9:42).  In  the 
formulation  of  responsibilities,  the  users  are  directly 
involved  in  policy  setting,  and  the  acceptance  by  the  users 
of  any  formulated  policy  is  mandatory.  It  is  only  with  the 
users  involvement  that  the  System  Manager  can  determine 
what  the  user  needs,  what  weapon  system  impacts  are  present, 
how  critical  the  change  request  is,  how  the  change  is  to  be 
employed,  and  how  well  the  current  ECS  performs  (36:57). 

The  management  function  must  be  committed  at  all  times  to 
the  actual  status  of  the  ECS  and  to  assuring  the  most 
responsive  support  is  being  provided  within  the  required 
configuration  control  requirements  (36:40). 

DESIGN 

ECS  design  is  the  logic  by  which  the  weapon  system 
receives  inputs  from  the  external  environment,  interprets 
the  input,  and  then  makes  decisions  that  result  in  displays, 
responses,  or  commands  to  weapon  system  subsystems  (2:31). 
The  design  requirements  are  derived  by  the  user  and  any 
alterations  or  changes  to  those  requirements  requires  the 
concurrences  of  the  user  (29:183).  The  structure  of  ECS 
is  the  method  of  developing  the  software  program.  Usually 
for  software  support  considerations,  the  underlying  concept 
is  a  top-down  design  which  leads  eventually  to  modular 
structure  of  the  program  (13:11).  The  top  down  design  is 
a  software  programming  method  which  starts  at  a  very  general 
level  by  identifying  major  functions  and  proceeds  stepwise 


to  lower  levels  to  the  identification  of  lesser  functions 


*£bat  ^a.re^iier.i  vai  £rom.tb«  major  onca  «(«13 :1&)  . ..  Tha  design ' s 
unity  in  terms  of  structure  and  requirements  is  fundamental 
to  both  the  user  and  the  support  function.  The  important 
ECS  design  concept  is  that  each  step  is  laid  out  and  defined 
and  will  facilitate  support  that  is  responsive  and  within 
configuration  control  requirements  (25:43).  Changes  that 
occur  in  an  operational  ECS  are  mainly  due  to  design  errors 
and  not  requirement  changes.  Design  errors  result  from  ECS 
that  was  poorly  designed,  inflexible,  and  required  exten¬ 
sive  higher  generation  computer  technology.  Design  errors 
are  more  prevalent  when  the  support  of  the  ECS  has  been 
distributed  among  various  organizations. 

PLANNING 

'  The  lack  of  planning  is  a  dominant  cause  of  programming 
reworks  and  System  Management  failures  to  comply  with  respon¬ 
siveness  requirements  (12:52).  Planning  for  software  main¬ 
tenance  in  general  is  a  function  that  is  rarely  accomplished 
(8:126).  Planning  includes  development  of  a  methodical 
procedure  designed  to  provide  an  acceptable  course  of  action 
for  resolution  of  an  ECS  change  request.  Traditionally, 
planning  is  poor,  with  little  or  no  time  spent  on  this  vital 
activity  (16:3-192).  The  lack  of  strategic  planning  results 
in  ineffective  management  and  control  over  the  ECS  and 
impacts  configuration  control  (26:3.7).  In  order  to  reduce 
the  impact  of  implementation  and  conversion  problems 
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associated  with  ECS,  planning  must  be  accomplished  through¬ 
out  the  Life-Cycle  of  the  program.  Plans  establish  a  course 
of  action  and  provide  management,  configuration,  control, 
responsiveness  and  related  goals  with  which  to  evaluate 
performance  (36:39).  The  organization  and  establishment  of 
plans  to  deal  with  corrective  actions  is  essential  for 
change  request  resolution  (27:4.5).  The  degree  of  planning 
performed  determines  the  extent  of  control  possible  and  the 
greater  the  extent  of  careful  planning  in  all  areas  the 
more  support  flexibility  the  ECS  has  (22:73) . 

DOCUMENTATION 

»  >  «  •  •  I  -  * 

The  extent  and  level  of  documentation  required  for 
each  ECS  acquisition  is  hard  to  evaluate  since  short  comings 
in  the  procured  documentation  is  not  apparent  until  there 
exists  a  need  (28:135).  However,  the  lack  of  documentation 
is  another  make-or-break  point  for  ECS  responsiveness  and 
configuration  control.  ECS  is  designer  dependent  and  serious 
failures  in  the  description  of  a  system  can  occur  when  the 
designer  does  not  or  improperly  documents  his  support  actions 
(28:136).  Traditionally,  determination  of  the  adequacy  of 
the  operational  documentation  for  ECS  is  on  the  employee 
rather  than  on  regulations  or  supervisors.  The  adequacy 
of  the  documentation  varies  with  each  programmer  (35:188). 
Good  programmers  who  optimize  design  coding  are  usually 
less  skilled  at  documenting  their  actions.  Instead,  they 
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tell  what  that  code  does  instead  of  what  it  is  which  is 
required  (25:53*)  .  'The*  existence  of  proper  documentation 
minimizes  errors  that  occur  when  trying  to  detect  an 
existing  problem  (25:91) . 

For  support  of  ECS  after  software  acceptance,  the 
quality  of  the  documentation  must  meet  standards  that  many 
organizations  have  not  developed  or  are  not  meeting  (31:77). 
An  extensive  listing  of  deficiencies  are  specified  in 
"Report  of  Functional  Management  Inspection:  Management  of 
Embedded  Computer  Software"  (2) .  Comprehensive  and  current 
ECS  documentation  is  necessary  for  the  continued  efficient 
operation  and  success  of  any  software  maintenance  function. 
The  greater  the  correlation  of  the  documentation,  testing, 
and  actual  software  code  the  easier  the  system  is  to 
support  within  response  and  configuration  control  require¬ 
ments  (28:126).  The  long  term  effectiveness  of  a  complex 
ECS  is  dependent  on  the  accuracy  and  adequacy  of  the  docu¬ 
mentation  associated  with  that  ECS.  As  the  maintenance 
programmer  moves  between  the  documentation  and  the  code  in 
his  maintenance  activities  the  correspondence  between  the 
code  and  the  documentation  is  directly  related  to  the 
success  and  ease  of  his  maintenance  effort  (25:51).  Pre¬ 
cise  documentation  of  the  characteristics  of  the  code  is 
essential  and  should  be  of  an  Air  Force  approved  standard 
notation.  This  because  it  is  easier  to  specify  an  ECS 
modification  when  that  modification  is  referenced  to 
existing  clear  and  well  integrated  ECS  documentation.  All 


changes,  whether  modification  or  problem  resolution,  must 
be  documented  by  written  statements  showing  reason  for  the 
change,  its  effect,  and  its  approval.  Each  release  of 
software  must  be  accompanied  by  release  documentation 
(12:284).  All  release  documentation  must  be  compatible 
with  existing  ECS  documentation  (29:267).  The  important 
consideration  is  that  ECS  documentation  exists  and  is 
maintained  current. 

REQUIREMENTS 

One  of  the  most  important  contributors  to  the  estab¬ 
lishment  of  an  effective  response-oriented  System  Manage¬ 
ment  function  lies  in  the  area  of  software  requirements 
definition  and  documentation  (8:180).  The  ECS  requirements 
generation  and  definition  phase  is  a  user  oriented  activity 
and  is  accomplished  in  close  coordination  with  designer 
and  user  (29:32).  It  is  the  responsibility  of  the  users 
to  specify  in  detail  the  requirements  for  the  ECS,  identify 
the  application,  and  the  environment  in  which  the  program 
will  be  utilized  (9:116).  When  the  users  assume  a  major 
responsibility  for  requirement  definition,  there  exist 
problems  in  the  convertability  of  those  requirements  from 
the  operational  environment  to  the  design  environment. 
Therefore,  it  is  implicit  in  the  generation  and  definition 
of  requirements  that  the  requirements  be  in  final  form, 
relatively  stable,  and  not  subject  to  change.  This  neces¬ 
sitates  that  requirements  be  complete,  consistent,  testable, 
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traceable,  and  flexible  (23:40).  Users  and  the  System 
Manager  assess  and  assign  priorities  to  the  ECS  require¬ 
ments.  This  insures  that  the  requirements  do  not  preclude 
effective  logistics  support  and  that  the  required  support 
is  conducive  to  the  user  dictated  responsiveness  require¬ 
ments  for  the  System  Manager  (1:10).  ECS  that  becomes 
operational  that  does  not  satisfy  user  requirements  is 
usually  the  result  of  inadequately  defined  requirements  or 
insufficient  testing.  Functions  to  be  assumed  by  the  ECS 
must  be  clearly  defined  and  documented  (10:73).  The  docu¬ 
mentation  of  the  requirements  is  in  the  form  of  functional 
descriptions,  system  description  manuals,  system  require¬ 
ments  manuals,  technical  requirements  manuals,  and  various 
levels  of  System  and  Subsystem  Specifications.  Deficiencies 
in  user  requirements  documentation  results  in  the  wrong 
interpretation  of  user  needs  or  design  of  ECS  that  is  inade¬ 
quate  or  not  operationly  suitable  to  its  environment  (26:3.8). 
Suspected  errors  in  requirements  necessitates  claraf ication 
both  of  the  requirements  in  question  and  its  documentation 
(18:72).  The  guiding  principle  in  this  instance  is  that 
requirements  are  generated  by  the  user  to  satisfy  an  opera¬ 
tional  need  and  as  such,  the  interpretation  of  those  require¬ 
ments  must  coincide  with  his  needs  (8:53). 

The  user  operational  needs  translated  into  ECS  require¬ 
ments  and  the  corresponding  responsiveness  required  for 
support  of  those  needs  and  requirements  directs  the  estab¬ 
lishment  of  support  standards.  A  successful  standards 
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program  must  have  the  direction  and  support  of  both  the  user 
and  the  System  Manager  management.  These  standards  serve 
as  support  and  responsiveness  goals  for  the  System  Manager 
in  his  support  function  and  as  a  basis  for  evaluating  their 
performance  in  providing  support  responsiveness  (20:81). 
These  standards  must  address  all  aspects  of  the  ECS  and 
adherence  to  the  standards  must  be  diligent  and  serve  as  a 
working  guide  for  the  support  function  (8:133). 

MAINTAINABILITY 

The  capability  of  the  System  Manager  to  provide  the 
required  responsiveness  is  directly  determined  by  the 
maintainability  of  the  ECS.  The  effectiveness  of  the 
System  Manager  in  providing  support  and  responsiveness  is 
determined  in  large  part  by  the  ease  of  maintenance  built 
into  the  ECS  (32:3.189).  The  primary  objectives  in 
designing  ECS  and  its  changes  are  to  minimize  the  amount 
of  initial  maintenance  actions  required  to  correct  designed- 
in  errors  and  to  allow  the  necessary  maintenance  actions  to 
be  accomplished  as  rapidly  as  possible  and  as  simply  as 
possible  (31:77).  This  equates  to  the  reliability  of  the 
ECS.  Software  reliability  is  the  probability  that  a  com¬ 
puter  program  will  perform  to  its  intended  function  for  a 
specified  time  interval  under  stated  conditions  (13:16). 
Dimished  software  reliability  is  due  to  bugs  and  errors 
in  the  program  which  result  from  poor  design,  inadequate 
testing,  improper  maintenance,  and  improper  software 
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modification  (10:136) ,  The  optimal  maintenance  path  to  be 
utilized  for  ECS  is  commonly  not  possible  because  (1)  choice 
points  and  logical  elements  of  a  program  are  not  well 
defined  and  (2)  documentation  is  not  adequate  enough  to 
allow  the  programmer  to  assess  the  "correctness"  of  his  effort 
in  providing  corrective  action  (25:54).  The  changing  of  a 
program  is  sometimes  more  difficult  than  the  writing  of  an 
original  program  because  of  the  "rippling"  effect  of  errors 
caused  by  the  original  error  In  addition,  there  are  errors 
that  are  induced  by  the  corrective  action  (5:45).  Program 
changes  or  modifications  can  insert  jumps  into  the  program 
that  further  complicate  the  program  and  decrease  its  under- 
standability  and  readability  (10:141).  Continual  changes 
and  updates  to  ECS  increasingly  make  the  program  hard  to 
understand  and  to  maintain.  When  this  condition  is  coupled 
with  management's  inaccurate,  incomplete,  and  uninformed 
approach  to  software  management,  software  maintainability 
is  extremely  impacted.  The  actions  necessary  to  insure 
an  ECS  is  maintainable  requires  creation  of  specific  main¬ 
tenance  dedicated  group  to  ensure  incorporation  of  known 
ECS  characteristics  in  the  maintenance  practices  and  identi¬ 
fication  of  maintenance  tools. 

USER 

The  user  is  that  organization  that  has  the  operational 
needs  for  which  the  ECS  requirements  were  developed  to 
satisfy.  Consequently,  only  the  user  has  the  full  knowledge 


of  the  operational  environment  in  which  the  ECS  is  to  be 
utilized  (29:13).  When  any  ECS  is  accepted  and  placed  in 
use,  its  operational  use  is  determined  solely  by  its  users 
(32:3-190).  Software  that  is  maintained  (1)  with  only 
average  input  from  or  understanding  and  support  of  users 
or  (2)  by  those  whom  the  user  disagrees  with,  has  an  ECS 
usage  failure  probability  rate  that  rises  geometrically 
with  lessening  user  support  and  participation  (29:13). 

User  ECS  support  is  determined  in  terms  of  the  reliability, 
timeliness,  economy,  range  of  choice,  and  flexibility  of 
support  the  user  receives  from  the  support  organization 
(31:9).  Therefore,  user  participation  must  be  included  in 
every  phase  of  the  software's  development  and  operation. 

The  importance  of  users'  concurrence  and  participation  in 
support  or  operational  decisions  cannot  be  over  stressed. 

A  symptom  of  inadequate  software  management  is  the 
lack  of  user  involvement  and  commitment  which  is  caused  by 
inadequate  user  responsibility  definition  (16:3-193).  The 
user's  responsibility  in  the  support  activity  is  a  critical 
factor  in  the  ECS  maintenance  and  support  and  those  respon¬ 
sibilities  require  detailing.  The  user  must  take  on  a  major 
responsibility  for  ECS  support.  There  must  exist  a  clear 
and  detailed  understanding  of  those  responsibilities  that 
belong  inherently  to  the  user's  and  those  that  are  the 
System  Manager's. 


Ill 


No  ECS  support  effort  can  be  initiated  and  accom¬ 
plished  successfully  without  user  involvement  and  commitment 
to  the  software  requirements  (8:55).  Software  requirements 
determination  are  a  user  oriented  activity  (29:32).  It  is 
the  responsibility  of  the  user  to  specify  in  detail  all 
the  software  requirements  and  the  associated  maintainability 
and  responsiveness  requirements.  Once  these  requirements 
have  been  identified,  it  is  important  that  the  user  commit 
to  them  and  that  they  be  defined  rigidly  and  established 
solidly  in  the  appropriate  documentation  (29:183).  Since  a 
substantial  portion  of  the  modifications  or  enhancements 
to  ECS  are  user  initiated,  the  user  must  be  directly  in¬ 
volved  in  the  preparation  of  the  policies  necessary  for 
successful  support  (10:73).  There  should  exist  a  direct 
relationship  between  the  user’s  plans  and  the  System 
Manager's  plans  so  that  the  latter  provides  the  necessary 
support  to  assure  the  former  can  accomplish  their  objectives. 
In  either  case,  key  and  final  decisions  in  planning  and 
probably  in  budgeting  must  be  user  supported  (31:36).  When 
responsibility  for  software  configuration  is  vested  in  a 
support  function,  the  System  Manager  familiarity  with  user 
needs  and  requirements  and  must  minimize  quality  control 
and  maintenance  change  requests  (10:12).  For  maintenance 
change  requests,  there  are  basically  two  types:  design 
and  discrepance.  Design  problems  occur  when  the  software 
does  not  or  does  not  seem  to  satisfy  user  operational  require¬ 
ments.  Misleading  user  requirements  or  the  accepting  of 
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verbal  user  requirements  as  design  objectives  versus  the 
documented  requirements  are  the  cause  of  user  design  prob¬ 
lems  (26:3-8).  A  functional  description  of  the  software 
provides  the  user  with  a  clear  statement  of  the  operational 
capabilities  of  the  system  to  be  developed  and  requires 
formal  user  approval.  Discrepancy  problems  are  problems 
that  are  identified  as  a  result  of  the  operational  use  of 
the  software.  The  user  must  define  these  problems  expli¬ 
citly  prior  to  change  development.  The  emphasis  must  be 
to  assure  that  the  corrective  action  corresponds  to  the 
problem  identified  by  the  user.  The  user  must  utilize  effec¬ 
tive  management  by  attempting  to  the  greatest  extent  possible 
to  minimize  continual  changes  which  disrupt  and  delay  the 
system's  utilization  (10:4). 

TEST 

The  testing  of  ECS  is  one  of  the  most  important  and 
most  frequently  abridged  or  skipped  steps  vital  to  an 
effective  software  program  (23:3.193).  The  objective  of  the 
ECS  test  is  to  bring  together  all  subprograms  of  the  ECS 
and  to  verify  that  they  fit  together  and  operate  smoothly 
as  designed.  There  exists  no  theoretical  way  to  prove 
that  the  software  so  tested  is  absolutely  correct.  This 
fact  usually  results  in  the  failure  to  test  or  incomplete 
testing  (7:18).  However  incomplete,  testing  of  software 
changes  to  the  ECS  prior  to  release  for  operational  use  is 
vital  to  assuring  that  the  system  continues  to  meet  the  re¬ 
quirements  specified. 


EXECUTIVE  STEERING  COMMITTEE 


The  Executive  Steering  Committee  is  an  organization 
established  at  the  corporate  level  whose  purpose  is  to  pro¬ 
vide  overall  software  management  guidance.  The  membership 
of  this  group  is  not  specified  except  that  a  software 
user  representative  is  mandatory  (29:16).  The  Executive 
Steering  Committee  provides: 

1.  Approval  and  prioritization  of  software  projects 
from  a  corporate  view  considering  challenge,  opportunity, 
and  associated  problems  (5:31). 

2.  A  maintenance  philosophy  taking  into  considera¬ 
tion  controversial  but  necessary  software  changes  and  user 
approval  and  coordination  (31:9-10) . 

3.  Assessment  and  identification  of  critical  soft¬ 
ware  requirements  (31:37). 

4.  Management  decisions  during  development  of  com¬ 
plex  programs  (10:76). 

It  is  this  group  that  determines  the  orientation  and  success 
of  ECS  management  by  specifing  management  concept,  a  support 
posture,  and  the  responsiveness  requirements  (4:156).  In 
determining  responsiveness  and  support  goals  for  ECS  manage¬ 
ment,  the  goal  definition  process  is  performed  considering 
the  software,  its  performance  requirements,  and  the  user 
required  responsiveness  and  defining  specific  goals  that 
are  a  realistic  interpretation  of  these  requirements.  The 
effective  utilization  of  personnel  and  resources  and  the 
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evaluation  of  the  support  organizations  progress  towards 
these  goals  achievement  is  a  primary  function  of  the 
Executive  Steering  Committee.  Its  operational  role  encom¬ 
passes  assessment  of  software  support  direction,  instituting 
means  to  provide  better  support,  and  planning  and  partici¬ 
pating  and  promoting  effective  communication  between  user 
ans  System  Manager  (24:30160).  The  effective  functioning 
of  this  group  significantly  assists  efforts  to  manage  soft¬ 
ware  effectively  and  provides  protection  to  lower  level 
designers  from  sudden  external  pressures  for  software  change. 
A  critical  function  of  the  Executive  Steering  Committee  is 
the  careful  nuturing  of  user  communication  and  relationships 
and  assuring  that  these  activities  extend  from  the  corporate 
level  to  the  day-to-day  software  support  operations.  The 
committee  is  the  primary  management  organization  responsible 
for  assuring  responsive  support  is  provided  users. 

Most  problems  that  exist  between  users  and  System 
Managers  originate  with  this  group.  Problems  in  communica¬ 
tion,  responsiveness,  and  inadequate  support  are  attributable 
to  the  Executive  Steering  Committee  being  comprised  of 
individuals  that  are  unable  or  unwilling  to  spend  time  to 
insure  a  firm  grasp  of  factors  significant  to  the  economies 
of  managing  software  effectively  (36:25).  Typically,  this 
is  when  the  individuals  on  the  committee  view  the  essential 
invisibility  of  software  as  an  unsurmountable  problem. 

The  basic  management  rule  that  no  manager  with  responsibility 
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will  base  critical  and  important  decisions  on  a  solution 
to  a  process  which  he  himself  does  not  adequately  understand 
applies  to  the  Executive  Steering  Committee.  The  visible 
evidence  of  an  Executive  Steering  Committee  that  it  is 
unwilling  or  unable  to  perform  its  function  is  user  communica¬ 
tion  problems,  priority  problems,  and  management  layering 
meaning  that  support  and  responsiveness  to  user  requirements 
are  adversely  affected  (3:115). 

PERSONNEL 

The  greatest  determining  factor  of  where  to  locate  the 
ECS  support  function  is  maintenance  personnel  availability  . 
The  maintenance  programmer  has  absolute  control  over  ECS  and 
its  operability.  Consequently,  the  continuity  of  program¬ 
mers  is  of  paramount  interest  to  the  support  organization  in 
its  ability  to  provide  responsive  and  effective  support. 

The  emphasis  in  an  ECS  support  environment  is  on  teamwork 
and  group  supervision  towards  commonly  accepted  goals  in 
terms  of  responsiveness  and  configuration  control  (21:30). 

The  achievement  of  high  performance  goals  by  support  per¬ 
sonnel  in  terms  of  responsiveness  and  configuration  control 
is  directly  linked  to  the  personnel  associated  with  pro¬ 
viding  that  support.  Many  problems  experienced  in  the  ECS 
environment  are  the  result  of  personnel  problems  and  the 
degree  of  interdependency  between  ECS  and  the  personnel 
maintaining  that  software.  Personnel  problems  encompass  the 
availability  of  qualified  individuals,  their  continuity. 


morale,  tenure,  capability,  and  experience  (1:15).  Con¬ 
tinuity  problems  impact  responsiveness  and  configuration 
control  because  as  maintenance  programmers  depart  the  organ¬ 
ization,  maintenance  slides,  the  maintenance  capability 
decreases,  error  correction  capability  diminishes,  and  the 
capability  to  provide  thorough  analysis  of  problems  is 
diminished  (12:171).  Software  support  is  not  a  glamorous 
function  and  does  not  naturally  attract  qualified  personnel 
although  such  are  required  (31:76) .  Program  maintenance 
is  often  considered  degrading  work  and  programmers  like  to 
work  on  new  projects,  therefore  the  maintenance  task  suffers 
(5:45).  The  ability  of  a  support  organization  to  be  res¬ 
ponsive  and  support  effectively  is  determined  by  the  degree 
of  turnover  in  systems  analysts  and  programmers.  Embodied 
within  these  individuals  is  much  of  the  planning,  specialized 
knowledge  of  the  problem  area,  and  detailed  or  unique  solu¬ 
tions  to  the  problems  that  are  not  documented  or  generally 
known  except  by  these  individuals  (31:22). 

Programmers  that  are  assigned  to  the  maintenance  func¬ 
tion  are  adept  at  finding  and  correcting  difficulties 
often  on  the  basis  of  meager  evidence  (5:109).  Experience 
of  these  individuals  is  directly  linked  to  their  ability  to 
interpret  a  program  and  diagnose  theproblems  (25:87). 
Comparison  of  novices  and  experienced  programmers  in  the 
maintenance  function  indicates  that  the  more  experienced 
personnel  can  correct  errors  at  a  faster  rate  than  the 
novices  (25:142).  This  is  a  critical  factor  in  an  ECS 
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support  function  that  is  response  oriented.  The  support 
organization  must  provide  the  greatest  stability,  rewards, 
and  opportunity  to  experienced  individuals  that  can  perform 
the  maintenance  function  in  order  that  these  individuals  may 
be  retained.  In  addition  to  experience,  these  individuals 
must  be  experts  on  the  hardware  capabilities,  the  software 
capabilities,  and  the  required  operational  role  of  the  system 
(8:183).  These  individuals  must  be  the  most  sophisticated 
senior  technicians  in  the  software  maintenance  installation 
and  form  the  hub  of  talent  required  to  provide  the  necessary 
responsive  support  to  the  user  (8:181).  These  persons  are 
by  responsibility  of  their  job  in  a  highly  creative  role  and 
are  expected  to  exercise  innovative  procedures  in  performing 
corrective  action  while  performing  in  real-time  (15:135) . 
Because  of  skills  and  experience  required  by  a  maintenance 
programmer,  the  demand  for  these  individuals  is  high  and 
provides  ample  opportunity  for  them  to  leave  the  organization. 
A  fundamental  purpose  of  the  support  organization  is  to 
insure  the  continuity  of  support  individuals  and  the 
availability  of  their  indispensable  skills. 
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Problem  Specification  Error  -  A  mistake  or  deficiency  which 
occurs  in  the  analysis  of  the  program  application  or  in 
specifying  the  software  requirements  with  respect  to 
the  intended  program  application  such  as  incomplete, 
erroneous  or  ambiguous  statements  (13:17-21). 

System  Design  Errors  -  A  mistake  or  error  made  in  the  trans¬ 
formation  of  user-oriented  program  specifications  into 
system  design  specifications  (13:17-21). 

Program  Design  Error  -  A  mistake  or  error  make  in  transform¬ 
ing  system  design  into  specific  algorithms  and  data 
structures  (13:17-21). 

Coding  Error  -  A  mistake  or  error  made  in  the  transformation 
of  program  design  into  source  language  (13:17-21). 

Clerical  Error  -  Any  human  failure  in  the  transformation  of 
one  step  of  a  program's  development  to  the  next  step 
(13:17-21) . 

Debugging  Error  -  The  inappropriate  use  of  debugging  tools, 
insufficient  or  inappropriate  test  case  selection,  or 
misinterpretation  or  debugging  results  (13:17-21). 

Testing  Error  -  The  inappropriate  or  insufficient  test, 

misunderstanding  of  functional  requirements  of  a  soft¬ 
ware  program,  or  test  plan  deviation  (13:17-21). 

Implementation  Error  -  A  mistake  or  error  resulting  from 
unexpected  environmental  problems  (13:17-21). 
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Communication  Error  -  A  mistake  or  error  derived  from  the 
improper  communication  between  members  of  a  programming 
team  or  due  to  inappropriate  system  design  specifica¬ 
tions  (13: 17-21) . 
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1.  What  is  responsiveness  for  an  ECS  change  request? 

la.  How  is  that  requirement  documented? 

2.  Is  that  requirement  the  SOP  utilized  for  respon¬ 
siveness  or  does  there  exist  other  guides? 

2a.  If  other  guides  exist,  what  are  they  and  how  do 
they  affect  the  responsiveness  requirement? 

3.  What  type  of  management  structure  exists  to  support 
the  responsiveness  requirement? 

4.  Does  there  exist  a  classification  method  of  change 
requests?  If  so,  what  is  it  and  how  determined? 

5.  What  is  acceptable  response  intervals  for  the 
various  types  of  change  requests? 

6.  tohat  actions  are  initiated  upon  a  receipt  of  a 
change  request  in  regards  to  other  work  in  progress  or 
waiting  processing? 

7.  How  is  the  criticality  of  a  change  request  deter¬ 
mined? 

8.  How  is  the  associated  corrective  action  priority 
established? 

9.  What  actions  are  associated  with  making  the 
corrective  action  release  available  to  the  user? 

10.  What  practices  are  established  to  ensure  effective 
communication  with  users? 


11.  What  has  been  done  to  prevent  and  lessen  the 
possibility  of  the  formation  of  duplicative  support  organi¬ 
zations? 

12.  What  is  "real-time"  change  request  resolution 
defined  to  be? 

13.  How  are  the  priorities  for  all  work  determined 
and  reevaluated  on  receipt  of  a  new  work  requirement? 

14.  How  is  the  importance  of  an  ECS  change  request 
related  to  the  weapon  system  and  its  operational  impact? 

15.  What  are  the  change  request  definition  require¬ 
ments  for  a  software  change? 

16.  What  are  time  requirements  associated  with  all 
evaluations? 

17.  How  is  error  validity  determined  and  when  an  error 
is  determined  invalid  what  disposition  actions  are  initiated? 

18.  What  testing  is  accomplished  for  corrective  actions 

19.  Is  corrective  action  allowed  by  user  organization? 

19a.  If  so,  what  limitations  exist  on  their  corrective 

action  capability  and  how  is  this  enforced? 

19b.  What  verification  of  user  corrective  action  is 
performed? 

19c.  What  is  the  relationship  between  user  initiated 
corrective  actions  and  the  support  organization's  corrective 
action  for  a  common  change  request? 

20.  What  safeguards  are  utilized  to  prevent  "crash" 
efforts  on  change  requests? 


21. 


What  initial  documentation  requirements  exist  for 


a  change  request? 

22.  What  are  the  requirements  for  correlation  of  a 
current  change  request  to  other  actions  that  may  be  associa¬ 
ted  with  that  change  request? 

23.  When  a  release  is  made  of  a  corrective  action  to 
ECS,  what  are  the  documentation  requirements? 

24.  Characterize  typical  problems  encountered  in  ECS 
and  how  extensive? 

25.  Does  there  exist  software  structure  requirements? 
If  so,  what  are  they? 

Control 

1.  What  control  requirements  exist  and  are  they 
documented? 

la. .  Do  the  documented  requirements  reflect  actual  SOP? 
If  not,  what  SOP  are  utilized? 

2.  How  were  the  control  requirements  determined? 

What  were  the  primary  considerations? 

3.  What  do  the  control  requirements  address? 

4.  Is  there  a  single  point  of  management  for  the  ECS? 
4a.  If  so,  what  is  the  extent  of  their  authority? 

4b.  What  is  the  relationship  between  the  single  point 
of  management  and  the  user? 

4c.  What  are  the  main  control  functions  of  the  single 
point  of  management? 
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3.  To  what  extent  does  "management  by  reaction" 
characterize  management's  operation? 

3a.  What  procedures  are  established  to  prevent  manage¬ 
ment  by  reaction? 

6.  What  internal  control  requirements  have  been 
established? 

6a.  Were  these  requirements  determined  jointly  with 
the  user?  If  so,  to  what  extent  was  user  participation 
and  of  what  scope? 

7.  What  controls  are  established  over  documentation, 
both  original  and  updates? 

8.  How  are  control  functions  assigned  and  what  is  the 
responsibility  distribution  and  relationships? 

9.  Do  measurement  standards  exist  to  evaluate  organ¬ 
ization  effectiveness? 

9a.  How  were  these  standards  determined? 

10.  Is  your  organization  a  centralization  or  decen¬ 
tralized  function  and  why? 

11.  What  is  the  user's  role  in  your  control  require¬ 
ments.? 

Communication 

1.  What  is  the  nature  of  communication  between  System 
Managers  and  the  users? 

2.  What  is  the  extent  of  management  between  user  and 
System  Manager? 

3.  Do  breakdowns  in  communication  occur  and  if  so, 
what  is  their  cause? 
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4.  How  critical  is  the  initial  information  sent  to 
the  support  organization?  What  requirements  exist  for  that 
initial  transmission? 

5.  What  is  the  nature  of  communication  lines  between 
programmers  and  users?  How  is  this  ensured? 

6.  What  emphasis  is  placed  on  communication  with  the 
user  and  how  is  this  implemented? 

7.  What  is  the  scope  of  the  interface  between  user 
and  System  Manager? 

8.  Are  communications  channels  vertical,  horizontal, 
or  what?  Why? 

9.  What  management  structure  supports  the  communica¬ 
tion  requirements  of  the  organization? 

10.  How  vital  is  communication  with  the  user  to  the 
organization? 

11.  Is  there  a  correspondence  between  life  cycle  of  a 
problem  and  communication?  Why? 

Management 

1.  What  are  the  key  functions  of  the  organization's 
management? 

2.  How  clearly  are  the  responsibilities  within  the 
organization  and  external  organizations 's  delineated? 

What  are  these  delineations  and  how  enforced? 

3.  What  is  management's  role? 

4.  How  are  management  practices  determined? 
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5.  What  requirements  or  procedures  are  in-being  to 
assure  single  point  of  management? 

Design 

1.  What  requirements  exist  for  the  design  of  software 
corrective  actions? 

Planning 

1.  What  planning  is  performed  in  support  of  the  ECS? 

2.  What  management  practices  are  utilized  to  assure 
effective  planning? 

3.  How  are  plans  maintained? 

4.  Do  long  range  plans  exist  and  are  they  practical? 
Documentation 

1.  Do  shortcomings  exist  in  documentation?  If  so, 
what  practices  are  utilized  to  circumvent  this  problem? 

2.  What  is  the  impact  of  documentation  not  being 
available? 

3.  What  requirements  are  levied  for  the  documentation 
of  change  requests? 

4.  How  is  the  documentation  of  corrective  actions 
performed? 

5.  Do  standards  for  software  documentation  exist? 

Are  they  utilized? 

6.  Does  there  exist  a  correspondence  between  docu¬ 
mentation  and  the  reliability  of  an  ECS? 

7.  Is  support  of  ECS  documentation  dependent?  How? 
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Requirements 

1.  Who  is  responsible  for  software  requirements 
origination  and  validation? 

2.  What  requirements  exist  for  the  definition,  scope, 
and  application  of  requirements? 

3.  To  what  extent  are  requirements  subject  to  change 
and  how  frequently  is  this  exercised? 

4.  What  constitutes  complete,  consistent,  traceable, 
and  flexible  requirements? 

5.  What  is  done  to  ensure  that  the  user  requirements 
are  effectively  interpreted  by  the  support  organization? 

6.  What  is  the  correlation  of  user  needs  and  design 
requirements? 

7.  What  standards  exist  that  are  associated  with  the 
requirements,  both  for  the  user  and  the  support  organization? 

Maintainability 

1.  How  is  ease  of  ECS  maintenance  determined? 

2.  How  is  the  reliability  of  the  ECS  determined? 

3.  How  are  updates  and  modifications  to  ECS  evaluated 
to  determine  impacts  and  increases  in  difficulty  of  main¬ 
tenance? 

4.  How  often  is  revision  of  the  ECS  performed  to 
enhance  maintainability? 

5.  Who  performs  the  maintenance  function? 
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User 


1.  What  is  the  relationship  between  the  user  and  the 
support  organization? 

2.  What  is  the  role  of  the  user  in  the  maintenance  of 

ECS? 

3.  What  concurrence  and  participation  requirements 
are  levied  on  users  for  software  maintenance? 

4.  To  what  degree  is  the  commitment  of  users  to  a 
software  program  important? 

5.  What  is  the  relationship  between  requirements  and 
the  user? 

6-  What  is  the  users  responsibility  for  corrective 
actions? 

7.  How  critical  is  user's  involvment  to  the  System 
Manager's  activities? 

Test 

1.  What  role  does  testing  play  in  ECS? 

2.  What  is  the  criteria  for  performing  tests  for 
corrective  action  software? 

Executive  Steering  Committee 

1.  What  is  the  purpose  of  the  organization's  top 
leadership  in  regards  to  software? 

2.  Are  management  problems  resulting  from  policy 
or  lack  of  policy? 
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Personnel 


1.  Are  personnel  critical  to  the  functioning  of  your 
organization?  Why? 

2.  To  what  degree  is  your  organization  dependent  on 
programmers? 

3.  What  are  the  required  qualifications  for  program¬ 
mers? 

4.  How  extensive  and  important  is  experience,  con¬ 
tinuity,  and  expertise? 

5.  What  is  the  normal  length  of  tenure  of  programmers? 

6.  What  is  the  level  of  expertise? 

7.  What  is  the  level  of  experience? 

8.  What  is  the  mode  of  maintenance  operation,  con¬ 
tractor  dependent  or  organic? 
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ACT 

REG 

ACT 

ACT 

QUE 

ACT 

par 

REG 

ACT 

ACT 

SIN 

REG 

ACT 

ACT 

STA 

ACT 

SIN 

ACT 

REG 

ACT 

STA 

ACT 

QUE 

ACT 

PAR 

STA 

ACT 

STA 

ACT 

STA 

ACT 

STA 

ACT 

STA 

ACT 

STA 


58 ,35, (8) .9* 

35 /CCS, 1,1,  n,  I* 

33,5  9* 

59/CC3,0,,0,S/5, (10) 35* 
36,5 ,39/37  ,31* 

36  ,37 ,  UN ,  17 , 20/CC3  0 , 1*. 

37  ,1,1, P* 

37.38,  (8)  .  1* 

33 /NOTE, 1,1  ,D,I* 

37. 39,  (8). 9* 

39/AP?,l  ,1, 0,  I* 

39,48* 

40.1.1, P* 

*8,44, (8).S‘ 

40.41,  (8) .5* 

41/HQAFLC,r ,, o»S/5* 

41. 42,  UN, 18 ,2 1/CC50 , 1* 

13, ,0. ,1620.* 

42 .1 . 1 ,  P* 

42.45,  (8) .9* 

42.43,  (8  )  .  1* 

43 /NOTE, 1,1,0, I* 

44 . 1 . 1 ,  P* 

44.45,  (8). 5  1 

44. 43,  UN, 17, ( 8) .5* 

•43  /INHOUSE,  1,  i,PI* 

45.45,  (8) ,1* 

45 /PA, 1,1, 0,1* 

43,69,  ( 2 )  •  9  ’ 

■33,1,1,0* 

60, 47, UF, 7, 23/FIX  TIME, 1* 
47 /FIX  CHG, 1, 1,0,1* 

47, *9* 

4g/WT  RELj  C,,D»S/3,  (10)  Sb* 

53. 43,  UN, 19' 

19,  ,3.  ,88*.* 
43/PRE0ES»i,i,D»I* 

43  ,33, UN, 19  * 

50/0 ETOES, 1,1, 0,1* 

50 ,51, UN, 19" 
vl/C-T,i,l,  0,  t* 
ii*3  2,  UN ,  19’"1 
32 /VALID, 1,1, 0,1* 

>2, 33, UN, 19* 

53/<P,l,l,0,I* 

53 ,54, UN, 19 

/CPCS9 , 1 , 1,  0,1* 


135 


ACT, 54, S3* 

QUE, 53/WT  REL,0,,0,S/3,  (10) 56* 

MAT, 56, 3, 49/57, 35, 26* 

ACT, 56, 37, UN, 17 ,25/OIST ,i* 
SIN,57/US£R,i,l,D,I* 

FIN* 

**♦  NO  ERRORS  DETECTED  IN  INPUT  DATA  *** 
***  EXECUTION  WILL  BE  ATTEMPTED  *** 
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FUNCTION  UF(IFN) 

COMMON/QVAR/NOc  ,N  Ft  3'.  (i  3  ii>  ,NREL  (l  3  3)  ,  NRZLP  (1  DO )  ,  NREL  2  ( 13  3)  ,NRUN, 
INRUNS  ,NTC  (IOC)  *  PAFAM  (iro  ,4)  ,T  BEG,  TNOW ,  Y,  A.NR,  AA,  EC,X  ,2Z ,XZ,  E,  EE  ,KK 
GO  TO  (1,2,3, 4,  5,  6,7  ),IFN 
IF  (TNOW,  Ec*3  •)  E  C=  "• 

IF  (TNOW, £Q, i), )  £  -2  CO. 

UF  =  (1 »/(  (  E/44 3 C  .)  -(EC/'-  400.)  )  ) 

Y=1,/UF 

RETURN 

UF=i,/,9 

X=C. 

,  AJ=ANR  ♦  1. 

IF(AJ.GT.c)  GO  TO  20 
X=(1./(Y*AJ>)  ♦  X 
AJ=AJ+1. 

GO  TO  10 
UF=UF*X 
RETURN 
IsTNOW/2190. 

UF=I+1 

RETURN 

UF=2 

A  A=TNO  4/168, 

AII=AA 

AA=(AA-AII)*153  . 

IF(AA,I»T,1U5»)GC  10  0 

UF=1 

GO  TO  E3 
AA=TN0W/24. 

A 11=  A  A 

AAa(AA-AII)  *24. 

IF  (AA  .  GE*  9. )  UF=  1, 

RETURN 

IF (AA • GE, 105, )  GO  TO  77 

UF=24,-AA 

GO  TO  30 

UF =15  3  ,-AA 

RETURN 

UF  =0 « 

AIIIaTNOW/2133,  +  1. 

A 1 11= A II 1*213 J» 

IFCTNOW.NE.AIII  )  GO  0  9 U 

£C=NTC  (25) -EC 

ANR*E-EC 

EE=ANR 

<K*1, 

GO  TO  95 
KK  =  0. 

RETURN 

YY= (E/44 G 0 . ) - ( E C/£  41  .) 
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XX=l./.9 

Z2=0. 

xz=o. 

AJJ=ANR  ♦  i. 

IF(AJJ.GT.E)  GO  T£  4: 
ZZ=(i./(YY*AJJ)  )  4  Z? 
XZ=(<1./(YY*AJJ))**21+XZ 


AJJ=A JJ+1. 

GO  TO  30 

A=XX*ZZ 

B=((XX-*2)*XZ) 

ALP=(  (A**2)/8) 

9  ET A= (9/A) 

AK=ALP 
K=  ALP 
FK=K 
GAM=U. 

XMAX= 100030* 

XMIN=  3 ♦ 

IF(K)  103,  103,10  1 
Pal.) 

DO  l!i  2  1  =  1, K 
P=P*RAnF(C.O) 
GAM=-1*<AL0G(3)  ) 

D=  AK-FK 

IF  ( 0-  .  015)  11C, 11C  ,13 
IF  (Q-. 93 5)106,1  J£  ,13  ; 

Ms  1,  C 
GO  TO  109 
AAA=1. 0/0 
39=1. 3/(1. 3-0) 
XA=<RANF(J.3))*  *A  /A 
YAs(^ANF  (0.0) ) * *99  4 'A 
IF (YA  *1. 3) 1C 5, 1 16  ,13  ‘ 
WsXA/YA 

YA=-i*  (AL0G(RANF(  £.3  1)) 
GAMsGAM  +  M  *YA 
GAHA=GAM*3ETA 
IF(GAHA-XMIN)121,  324,122 
GAMA=  XrllN 
GO  TO  124 

IF(GAMA-XMAX)  12’..,  124,123 

GAMA=XMAX 

UF=GA  HA 

IF(KK.£Q.l.)  i-zZ 

RETURN 

END 
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WA0E,TAC,3,5,  1930,20,7,  200 , 19000. , 3,  S,  (21  >43, 16* 
l,3,i,0,M* 

1.1, UF,l,l/PROBGEN,l* 

1. 2,  UF , 3 , 2/CORRACT , 1* 

2/CPCS9,l,l,P,I* 

2. 3,  UF, 2, 3/DISAP, 1, .5* 

2.4, UF,2,4/APP,1,.5* 

3/STOP  ACT, 1, 1,0,1* 

4/CHNG  ASSESS, 1,1, P, I* 

4,7, (3). 5* 

4.5,  (8)  .5* 

5/IMP  CHNG, 1, 1,0,1“ 

5,o,UF,4,5/FIX  TIM E ,  1* 

5/CLOSE  PR09, 1,1,0, I* 

7/ PR10 , 0 , , P  ,F* 

7, 3, UN, 5, (8). 5* 

5. . 0 . . 24.* 

7, 11, (8). 3* 

8/TAF  CCB,i,l,P,I* 

3,11,0)  .5* 

3,  9,(8),  .5* 

3/ CHNG  IM°, 9, ,0, F* 

9,  10  , UF,  4,  67F IX  TIME,1* 

10/DIST  CHNG, 1,1,0, I* 

11/TAFIG,1  j  1,0,1* 

11 .12,  UM,5 ,7/CHNGO.I  ST,  1* 

12/EVAL , 1, 1 ,0 ,1* 

12 .13,  UN, 5, 8/ROMTS , 1* 

6.. ,fl  «  ,  158.  * 

13.1.1,  P* 

13.14,  (3) .5* 

13.15,  (8)  ,5* 

14/SM-IM,1, 1,0,1* 

14,15* 

15 /T  AFIG,3, ,D,F* 

15»lS,UN,5i9/AGEN0A,l* 

16/TAF  CC3 , 1, 1,  P,  I* 

16.17,  UN, 3,  iO/OISAP,l,  .5* 

16. 18,  UN, 5, 11/ApP,  1 ,  ,5* 

17/0RIG,1, 1,0,1* 

18 .1.1,  P* 

13,34,  (3). 5* 

18.19,  (8). 5* 

19/IMP, 1,1,0,  I* 

19, 23, UF,'*,  12/FIX  TIME,1* 

23 .1.1,  p* 

23,25, (8). 5* 

23.21,  (3) . 5* 

21 .1 . 1 ,  P* 

21,33, (0).p* 

21.22,  (3).s* 
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STA 

ACT 

PAR 

REG 

ACT 

ACT 

“STA 

ACT 

STA 

ACT 

STA 

ACT 

STA 

ACT 

STA 

ACT 

REG 

ACT 

ACT 

QUE 

ACT 

PAR 

REG 

ACT 

ACT 

STA 

ACT 

STA 

ACT 

STA 

ACT 

ACT 

REG 

ACT 

PAR 

ACT 

REG 

ACT 

ACT 

SIN 

REG 

ACT 

ACT 

SIN 

STA 

ACT 

QUE 

ACT 


22/JTF,l,r,D,I* 

22 *23? UN 13 /JOINT TEST  ,1* 

7.. 0..720.* 

23*1, i,P* 

23.24,  (8). 5* 

23.25,  13  7*5* 

'25 /TEST  FAIL,  1Y1^D*"I*’~'  ‘ 

25,29* 

24/CERTIFY, i, 1,0,1* 

24,31* 

33 /NO  TEST, 1,1,0, I* 

39,31* 

26/TSlSC  ,1, 1,  0,1* 

26, 27, UN, 7* 

27 /TEST  EVAL, 1,1,0 , I* 
27,23* 

23.1 .1 , P* 

23,29, (3>. 5* 

28,31, (8), 5* 

29 /MOO  RQMTS, G,,0, F* 

29,23, UH, 8* 

3. . 3 . , 48 • * 

34.1 .1 , P* 

34.35,  (8). 5* 

34.36,  (3). F* 

35 /CLASS II ,1,1, 0,1* 

35. 36,  UN, 5, 16/CIICR,1* 
36/JS3 , 1, 1,  9,  I* 

36. 37,  UN, 5* 

37/JS9  ACT  ,  1, 1, P, I* 

37,35,  (8). 5* 

37.38,  (8), 5* 

33. 1.1,  P* 

38. 39,  UN, 9i  (8). 5* 

9..  9. .336.* 

38*41, UN, 9,  (Q),5* 

39.1.1 , P* 

39,12,  (8) •  5* 

39.40,  (8). 5* 

40/ST0P, 1,1, 0,1* 

41. 1.1,  P* 

41 *h2» (3). 5* 

41,43, <3).R* 

42/HIGHEr  CC9  tit 1,0,1* 

+3 /JSTND  CHNG,l,l,D,I* 
43,22* 

31  /CERT  9-L,D,,0,F* 
31,22,UN,3,14/CHNG  BL,l* 
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mmmw 


STAf 32/REUE»i» i »D,I* 

ACT,32,33,UN,9» 15/DIST » 1* 

SINt  33 /USER, 1,1, 0,1* 

FIN* 

***  NO  ERRORS  DETECTED  IN  INPUT  OATA  *♦* 
***  EXECUTION  WILL  BE  ATTEMPTED  ♦** 
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T" 


FUNCTION  UF(IFN) 

COMMON/QV.AR/NOE  ,N  FT3  l  (1 0  0) ,  NREL  (t  30)  ,  NRELP  (100) ,NREL2 (IOC) ,NRUN, 
INRUNS,  NTC  (IOC)  ,  FA  FAN  ll«  0 ,4)  ,  TBEG,  TNOW  ,  Y  ,  ANR,  EC,  ZZ,  XZ,  E 
GOTO  (1, 2,3,4)  ,1  fN 
IFCTNOW.EQ.O.)  A  NR  =23 
IF(TNOW.EQ.O.)£C=  C. 

IF  (TNOW#  EQ .0 •)  E -2  CO. 

UF*(l./(  (E/4430.)  -(EC/i-40a.))  ) 

Y=1./UF 
RETURN 
UF=l./.9 
X=  0. 

AJ=ANR  +1. 

IF(AJ.GT.E)  GO  TO  20 
X*  (1./ (Y*AJ))  ♦  X 
AJ  =AJ  ♦  l. 

GO  TO  10 
UF=UF*X 
RETURN 
UF=3 

IF  (TNOW.EQ.C.)  A  NR  =20  '. 

ANR=ANR-1. 

EC=E-ANR 

RETURN 

YY  =  (E/4430.)-(EC/  *43  -.) 

XX=l./.9  t 

AJJaANR  *  1. 

X7=G. 

ZZ=3. 

IF  (AJ  J  .GT  •  E)  GO  TC  V 
ZZ  =  (1./(YY  -  AJJ)  )  +  ZZ 
XZ=(1./(YY*AJJ)  >**2  *X7 
AJJ=AJJ  +  1. 

GO  TO  33 

CONTINUE  I 

A  =  XXX  ZZ 

R=((XX**2)*XZ> 

AL P-  (  (A**  2)  /P) 

BETA* (H/A) 

AK=ALP 
K=  ALP 
FK-< 

GAM=0 . 

XMAX=1C3003. 

XM IN=  3  • 

IF(K)  1^3,103, 1 J 1 

p«i.: 

00  U2  1*1, K 
Pa9*PANF(a.O) 
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GAM=-i*(ALOG<P> ) 
o=ak-fk 

IF  (0-. 015)110, ill  ,n 

IF<0-. 935)196,1  35  ,11' 

W=1.3 

GO  TO  109 

AA=i. 0/0 

39=1. 0/(1. 0-0) 


XA=<RANF(0.9))**A  * 
YA=<RANF(3.G))*  *9  9  +  ^A 
IF<YA-i. 0)108, 138  ,11" 
W=XA/YA 

YA=-1 . * ( ALOG ( RA  NF  H.2))) 
GAM=GAM  4  W  *YA 
GAMA=GAM*  BETA 
IF(GAMA-XMIN)121,  124,122 
GA  MA=XMIN 
GO  TO  124 

IF (GAMA-XMAX)  12  +,  124  .123 

GAMA=XMAX 

UF=GAMA 

E=  E-i  « 

RETURN 

ENO 
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GEN 

SOU 

ACT 

ACT 

STA 

VAS 

ACT 

REG 

ACT 

ACT 

ACT 

ACT 

REG 

VAS 

ACT 

REG 

VAS 

ACT 

REG 

VAS 

ACT 

REG 

ACT 

ACT 

ACT 

ACT 

REG 

VAS 

ACT 

REG 

V  AS 
ACT 
REG 

V  AS 
ACT 
REG 

V  AS 
ACT 
CUE 
ACT 
STA 
ACT 
REG 
ACT 
ACT 
ACT 
oAR 
ACT 
SIN 
CUE 
ACT 


NAPE,  I  As 


1 

1 
1 

2/ 

2 
9 


,3,r,193), 17,*»,  21 A  ,  1)03?.  ,3,S,  ,v,(2i)  5k,Z'+* 

hr 


•:,i,n,hr 

i>UF,i,t/oR03G2N,i* 

2* 

ISM  Tf0,l,l,C!,I* 

1.IS1* 

3,  ijE,  2 » 2/ ISO  PRO  5  *  1* 


if  i»  P* 

4,  m  ,12?" 
3* (?) .12?* 
10 f (3  ).5* 
11, (3). 2s* 
1,1,0* 

2, CO,?* 

t 

1,  1,0* 

2, CO, 3* 

13,1,1,0* 

1.1.2,  CO  ,7* 
10,7* 

11*1, 1*P* 
11,12,  (3).  2?" 
11,1*, (3) .25* 

11.16,  (3>.2E* 

11.17,  <3>.2'K 

12,i,l,DA 

12. 2,  CO, 1* 
12,7* 
l*v  ,1,1,0s 


1*  ,2, 


1^,7* 

15 ,1,1,Q* 
15  ,2, CO,  V 
15  ,?* 

17 ,1,1,0“ 
17, 2, CO,  3* 


17,-*  \ 

7/ PROOI D, 1 , ,D,S/1> 
7,03*  \ 

53/ISMTl"",  1,1,0, 
13, 23,tJ-,v* 


2  j  ,1 , 1 , r  ' 

21,22,, , 2?/rR ,1, , A  2.  EO.E* 

22.31,  (?)  12 • E0.&' 

21 .31,  UP', i,  7-V/T f.O  PC,1,  ,A2.tQ.7n 
>,  ,  * ,  2" « * 

21 .21, UN,?, (DA2.LE.4-* 

21  /n-L  ocT  ,  1,0,1  '• 

31,  ,,0,c' 

31 , -2, UP,", “/FIX, I* 
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STA»  32/04503  A,i,i,p,I* 
ACT,32,33,UN,6,C/APP,1,  .5“ 

P  A  R ,  5 ,  , 2*,45,A 
SIN, 33 /CLOSE, 1,1, 0,1* 
ACT,3?,34,UN,6,  <3/015 AP  , 1,.3* 
st a *3** /Remo  p,i,i,d,i» 

ACT, 3*, 33, UN, "‘ 

STA,  35/T10  90»i»i»p*I* 
ACT,35,37,,,12/T-F,i,.5* 
ACT,3P,3o,,,13/PERM,1, .5* 

REG , 36 , 1 , i , P* 

ACT, 36, 37, (6) ,5* 

ACT, 36,33,  (3)  .  =  ' 
QUE,37/SAS,0,,0,S/i' 

ACT ,37 ,^5,UF ,r  , 10 /FIX,  1* 
STA,4?/uT  OASCB  ,1,1, 0,1* 

ACT  ,-'*5, 46“ 

A  CT  ,45  3 ,  UH , "  ,  17  /OA SC  8 , 1* 

STA, 38/GEM  OR,l  ,1,P,I* 

ACT, 38  ,43,  (8)  .334* 

ACT,  38,31,  (3  )  •  333* 

ACT, 38  ,22,  (3). STS* 

REG, 39,1,1, 

ACT, 39 ,42, UN, 3,  (8) ,5“ 

ACT, 39, 42, UN, 3,  (8)  .5* 

STA,U2/MR,l,l,n,I* 

VAS,42,3,C0,i* 

ACT ,42 ,46* 

ACT ,42 3 ,UM ," , 14/APP  MV,i* 
QUE, 43/PAT  DEV,  ,0,S/1'- 
ACT, >3 ,ul, UF, 5, 11/FIX, 1- 
ST  A ,41 /T ^0  3D, 1,1,0, I* 

ACT ,41  3,UN ," »  16 /PAT  W  7 , 1  * 
ACT,  41  ,4 o'* 

DUS,  22 /GEN  CP.,r'»,0,F* 

ACT ,22, 23, UN, 3, 3/LIII  C  M,  1* 

?AR,3,,"«,338,*' 

STA,23/"VAL,1,1,0,I> 

A  CT  ,  23 , 24,  UN  ,P ,  •  /  EVAL ,  1  * 

PAR, 9,  ,  3  2P  •'* 

STA,2'/LIIICC9,1,1,P,I  + 

ACT, 2‘ ,25, (S) .c- 
ACT,2-‘,29,  <  3  )  -r- 

DUEjEv/^ETU^m,",  ,0,p* 

ACT, 2" ,23, UN, 3, "/ROUTE, 1* 
STA,  2-6  /■’•  P°EA L,1,1,°,I'- 
A  CT , 2 j , 27 ,  (3)  .rY 
SIN, 27 /CLOSE, 1, 1,0,1* 

ACT, 23, 23,  (3).c* 

REG, 23 ,i,l,or 
ACT,  23  ,27,  (3) 

A  CT  ,  2"1  ,2?,  (?)  • r* 
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e  * 


QUS,29/T\0  n0,  r'  , , D«  F* 

ACj,  29  » 3  C  » UF  ,5,(j/FIX»i* 

STA  »  33 /0A5C9  H, 1,1, 0,1- 
ACT ,33  ,46* 

ACT ,33 ,4  3, UN , 3 , 15/CR  WAIT»1V 
QUE,43/QASC9»', ,D,S/1x 
ACT, 43, 54* 

STA,54/CASC*,i,i, F,I» 

ACT,  54,1.x*,  (9)  Aj.EC.i* 

ACT, 34, ’*7,  (9)  AT  ,N£.i+ 
9EG,44,i,i,P* 

ACT, 44, 22, <?). 333* 

ACT, 44, 49,  (8).  333* 

ACT, 44, -,7,  (9)  .334* 
QU£,47/A»PACT, 9,,C,S/i, (in) 43* 
.0UE,>o/90C-PGH,  r,, 0,3/1,  (10)48* 

MAT,49,l,47/i 9, A£* 

A  CT  ,48  ,49,  UN  ,* ,  19/NNCpT ,  1* 

ST  A  ,49/MMC.9T ,  1, 1 , 0,  I* 

ACT  ,49  , 5  3 ,  UF,  3 , 2£/r.EL  S C H ,  l  ; 5 
STA,99/R£L,1,1,  0,1* 

ACT ,53 ,£i,  U?J,r  ,  21/PGM9n  ,  l* 
STA,51/SW  P£L,l,l,P,r‘ 

ACT,  31, 9  2,  !!■•!,",  32/DIST.l* 

SIN, “2, 1,1, 9, I* 

FIN* 


146 


FUNCTION  UF(IFN) 

COMMON/OVAR/N1Z,  NFT9U  (la  J)  ,NREL  CISC)  ,  NkELP  (1  lu  ) ,  NREL2<1JC)  ,NRUN, 
1NR UNS ,  NTC  CIS 8  > »  P  A  R  Arp  ( 1 :  0  ,  <t)  ,  T  S  EG,  TNO  W ,  EC ,  A  NR ,  Y ,  Z Z ,  XZ ,  E 
GO  TO  (1.2, 3**, 5) ,IFn 
IF(TNOW,£C.O.)EC  =  -). 

IF  (TNO W,  E 0.3  .)  E=  2  JO  • 

IF (TNO W. EQ«0 • ) ANR=23Q  • 

UF  =  ( 1  .  /  (  (E/4M3.)  -  (EC/V^Oa. ))  ) 

Y=1./UF 

RETURN 

UF*l./.9 

IF  (TNOW.EC.G.)ANR  =  2!3  J. 

ANR=6NR-1. 

A J  =AN  R  +  1. 

X=3. 

IF  (AJ.GT.  c)GO  TO  2G 
X=U./(Y*AJ))  +X 
A J=AJ  +1. 

GO  TO  10 
UF=UF*X 
RETURN 
UF  =1S  3 , 

RETURN 
U  F  2  J  • 

EC-E-ANR 

RETURN 

YY*(E/i<4--u.)  -(EC/-,40  0.) 

XX  =1 .  /  .9 
A J J=A  NR  +  1. 

XZ=). 

zz=o. 

IF(AJJ.GT.E)  GO  TO  AO 
77=(i./(YY>AJJ)  )  +  ZZ 
XZ  =  (1 ./(YY-AJJ)  +*2) +XZ 
AJJ—m  J  J+ 1 • 

GO  TO  3 J 

A -XX-'  Z7 

9=  ( CXX***  2)  *XZ) 

AL°=  (  ( A-**  2)/3) 

9ETA= ( 9/ A  ) 

AK’sAl  P 
K  -  A  I.  P 
FX=K 
G  Ays., 

X*'AXs  i  ;  j ;  30. 

XMI>|=  : . 

=  °INT  '.A.S.AL-’.BETA.AK.K.FX 
IF  (X) I.-3, 1C3. 1:1 
?=  1. 

00  1- 2  1=1, K 
c  =  ?  *PA»;f  (r 
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GAm=-1*(AL0G(F> ) 
D=AK-FK 

IF(0-.985)106»13?»12» 

W=i.ti 

GO  TO  109 


A  A  =1.  I/O 
99=1. 0/(1. 0-0) 
XA=(FANF(C.O))  -A  A  A 
Y  A  =  ( R  A  NF  (  O.ij)  )  •'  A  9  3  +  XA 
IF  (YA  -  1,  nio3,108,i:7 
N=XA/Y  A 

YA=-i  *  (ALOSIFANF (U.P) )} 

GAMsGAF  +  W  *YA 

GA^A  =  GAM->9ETA 

IF  (GA  YA-XMIN')  121 , 124 , 122 

GA.‘1A*XMIM 

GO.  TO  12*. 

IF  (GAMa-XMAX)  124 , 124, 123 
GA  MA=  XHAX 
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0153601 

STATION  IB  -AG 

04/1 1 /GO  create  8.341  2127 

user  id  -80A024.PC41 ,UP1186 
SYSTEN  T 

**ALL  USERS  CHECK  CQOE-A-PHONE  MESSAGE  177603) 


009-SYSTEN  UNKNOWN 

SYSTEN  TFQRT 

OLD  OR  NEU-OLD  FACTOR 

READY 

♦LIST 

010  DIHENS10N  FAC(24,13,13> ,REL<13,13> 

015  CHARACTER  A,B 
020  DO  20  1»1,24,1 
030  DO  30  J»1,13,1 
040  DO  40  K-1,13,1 
050  FAC1I lJfX)30. 

060  REL(J,K)*0. 

070  40  CONTINUE 
080  30  CONTINUE 
090  20  CONTINUE 

100  30  PRINT, "WHAT  IS  THE  AUTHOR'S  HUMBERT" 

110  READ, I 

120  IFd.EQ.100l  GO  TO  60 

129  PRINT, "UNAT  IS  THE  PRINCIPLE  -  MAIN, EXEC, PL AN, CHAN, H6HT,DESI, 

130  PRINT, "RQNT, CONN, DOCU, USER, PERS, TEST  -  INVOLVED?" 

131  READ, A 

132  IFIA.EQ.'NAIN')  J*1 

133  IF1A.E0. 'EXEC' ) J»2 

134  IF<A.EQ.'PLAN')J«3 

135  IF(A.E8.'CHAN' ) J*4 

136  IF( A.EQ.'CONT' )J»5 

137  IF<A.E0.'HGHT')J»6 

138  IFIA.EQ.'DESI' ) J«7 

139  IF (A.EQ.'RONT'iJaS 

140  IF (A.EQ.'CONN' )J«9 
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i4t  if<a.eq.'bocu'>>io 

142  IF (A.EQ.'USER' )>1 1 

143  IF(A*EQ*'PER8' )»2 

144  1F<A.EQ.‘'TEST/)  J«13 

145  PRINT t  "WHAT  13  THE  FACTOR?1* 

144  REAR, I 

147  IF(B.E0.'NAIN')K-1 

148  IF<B.EQ.'EXEC')K»2 

149  IF<B.EQ.'PlAH')K-3 

150  IF<B.EQ.'CHAN')K-4 

151  IF(B.EQ.'C0NT')K-3 
132  IF (B.EQ« 'M6HT' )K-4 

153  IF(B.EQ.'DESI')K-7 

154  IFIB.EQ.'RQNT' )X-8 

155  rF(8.EO.'COHH')K-9 
134  IF<8.EQ.'D0CU')K-10 

157  IF(B.EQ.'USER')k-11 

158  IF(B.EQ.'PER3-')K«12 

159  IF<B.Efl.'TEST')K«13 

170  FAC<I,J,K>-FAC<I,J,K>*1. 

180  80  TO  SO 
190  40  DO  70  1-1,24,1 
200  DO  80  Xs*!  ,13,1 
210  C-0. 

220  BO  90  >1,13,1 

230  C-FAC(I,J,K)+C 

240  90  CONTINUE 

243  IF<C.EQ.O.)  GO  TO  80 

250  DO  100  >1,13,1 

240  FAC(1,J,X)>FACU,J,K>/{C*24.) 

270  100  CONTINUE 

280  80  CONTINUE 

290  70  CONTINUE 

300  DO  110  K-1,13,1 

310  DO  120  >1,13,1 

320  DO  130  1-1,24,1 

330  REl<J,K>*REL<J,K>+FAC(!,J,K> 

340  130  CONTINUE 
330  120  CONTINUE 
340  110  CONTINUE 

370  PRINT  140,  ((REL(I,J),I»1 ,13>,>1,7) 
380  140  F0RHAT<//,2X,7<2X,F4.4)) 

382  PRINT  1S0,((REL(I,J),I-I,13>,>8,13) 
384  150  F0RNAT(//,2X,4(2X,F4.4>) 

390  STOP 
400  ENB 


ready 

* 
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0010*  SOFTWARE  MANAGEMENT  FACTOR 

O020NOTE  MANA6EMENT  PRINCIPLES  INTERRELATIONSHIP  FACTORS 

0030C  AA«.01 

0040C  AB*.02 

005 OC  ACS.03 

OOAOC  AB*.04 

0070C  AE-.OS 

0080C  AF=.04 

0090C  AGs. 07 

OIOOC  AH=.08 

01  IOC  AJ*.09 

0120C  AK=. 1 

O130C  ALs.11 

0140C  AHs.12 

O150C  AN*. 13 

OIAOC  AO*. 14 

O170C  AP*.1S 

0180C  AQ=.1A 

0190C  ARs.18 

0200C  AS*. 1 9 

021 OC  AT*. 2 

0220C  AU*.21 

023 OC  AV=.24 

O240C  All*. 28 

O250C  AX*. 29 

02A0C  AY*. 3 

0270C  AZ*.34 

0280C  AAA*. 37 

0290C  AAB*.38 

0300C  A AC*. 43 

031 OC  AAD* .47 

0320C  AAE*.48 

O330C  AAF«.SA 

O340C  A AG*. A 

O350C  AAHs.43 

03AOC  AAI=.A5 

O370C  AAJ*.7 

O380C  AAK* .74 

O390NOTE  UNITARY  FACTORS 

0400C  AAL*5 

041 OC  A AM* 8 

0420C  AAN*A 

0430C  AA0*9 

O440C  AAP*4 

O450N0TE  NANA6ENENT  PRINCIPLES  VALUES 
O460M0TE  EXECUTIVE  STEERING  COMMITTEE 
O470A  ESC.K*< AB*MAI)+< AAH*ESI)+(AO*PLI)+( AS*CNI )+ 

0480X  <AA*TEI)t<AA*REI> 


O490N0TE  MAINTAINABILITY 

0500A  HA. K*< AN*PLA.K)+( AB*CHI )+( AB*CNT . X )+( AZ*DEI )♦ 

OSIOX  ( AH*CMI )♦( AS*D0I )♦( AA*USE.K)-M  AT*PER.K) 

OS20N0TE  PLANNING 

0S30A  PLA.K=<AAJ’*ESC.K)+(AD*TEI)*<AK»DOI)+<AF*USE.K> 

OS40N0TE  CHAN6E  RATE 

OS50A  CHR.K=< AO*PLA.K)+< AAE*TES.K)+< AU*DES.K)t(AJ*REQ.K) 

0540X  ♦( AA*DOC.K) 

O570N0TE  CONTROL 

0580A  CNT.K*(AB»ESC.K)t(AAK*PLA.K)+( AF*PEI )+(AL*TEI )* 

OS90X  <AF*REI>+lAA»DOI> 

OAOONOTE  PERSONNEL 

0610A  P£R.K*(AL*CHI)+(AD»TEI)+(AAB!*N6I)*(AY*CMI)+(AD*D0I)+ 

0620X  (AN*USE.K) 

0630N0TE  TESTIN6 

0640A  TES.K*<AAA*ESC.K)t(AH»PLA.K)*(AA»CHI)+<AR»CNT.K)+(AK*TEI)+ 
0650X  ( AH*MGT.K)+( AL*REQ.K)+( AG*USE.K) 

O460N0TE  HANAGEHENT 

0670A  HGT.K®< AD*ESC.K)+( AA6*TEI )♦( AU*REQ.K )♦ (AC*DOC.K)+(AM*USE.K) 
OA80N0TE  DESIGN 

0690A  DES.K*< AE»CHI )♦ < AO*PER.K)+( AAD*DEI )+( AT*REQ.K) +< A0*CMI) 
O700N0TE  REQUIREMENT 

0710A  REQ.K=(AD*HA.K>t<AV*ESC.K)+(AX*CNT.K)+<AAC*NGI) 

O720N0TE  COMMUNICATION 

0730A  CHH.K=<AA»PLA.K)+(AA*CHT.K>+<AB*PER.K)+(AP*BOC.K) 

O740X  ♦<AAI*USE.K)+<AO*TES.K) 

O730N0TE  DOCUMENTATION 

0740A  DOC.K=<AE*MA.K)+<AJ*CNT.K)+<AAH*DES.K)+<AC*REQ.K)+(AT*DOI) 
O770N0TE  USERS 

0780A  USE.K3( AB*ESC.K)+( AB*CHI )+(AK*H6I )+(AB*DEI )+(AB*CHI)» 

0790X  (AM*DOI)+(AAF*USI) 

OBOONOTE  INITIAL  VALUES  OF  MANAGEMENT  PRINCIPLES  VARIABLES 

0810C  NAI=t 

0820C  TEI=1 

0830C  CNI-1 

0840C  ESI- 1 

08S0C  PLI*1 

084 OC  REI*1 

O870C  CHI*1 

0880C  DEI-1 

0890C  CNI*1 

0900C  D0I*1 

091 OC  PEI»1 

0920C  MGI*1 

0930C  USI-1 

Q940NQTE  INITIAL  FAILURE  LEVEL 
0950L  ILF.K*ILF. J-(DT) (FR. JK) 

0940N  ILF=200 
0970N0TE  FAILURE  RATE 
0980R  FR.KL*CHR.K*ILF,K*FRF 
0990C  FRF».04 
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1 0OO NOTE  FAILURE  RATE  FRACTION  BASES  ON  8  PER  UEEK 
t OIONOTE  SOFTUARE  ENGINEERING 
1020L  NME.K-MNE. J+(DT) (FR. JK-RR.JK) 

1 030N  MME*0 
1O40NOTE  REVIEU  RATE 
10SOR  RR.KLMMNE.K*RRF)/MRF.K 
1 040C  RRF*.05 

1O70NOTE  REVIEU  RATE  FRACTION  BASED  ON  4  HOURS  TO  REVIEU 
1080NOTE  HANA6ENENT  REVIEU  FACTORS 
109OA  MRF.K=(REQ.K+BOC.KtMA.K+OES.K+PER.K)/AAL 
1 IOONOTE  COMPUTER  PROGRAM  SCREENING  PANEL 
111 OL  CPS.K*CPS.  JMDTHRR.  JK-CR.JK) 

1 120N  CPS=0 

1 130NOTE  COORDINATION  RATE 
1 140R  CR.KL=(CPS.K«CRF)/CQF.K 
1150C  CRF=.025 

1 160NOTE  COORDINATION  RATE  FRACTION  BASED  ON  8  HRS  TO  COORDINATE 
1 I70N0TE  COORDINATION  FACTORS 

1 I80A  C0F.Ks(H6T.K+USE.K+PER.K+TES.K+D0C.K+CNM.K+DES.K+REQ.K)/AAM 
1 1 90NOTE  COMPUTER  PROGRAM  CONFIGURATION  SUB-BOARD 
1 200L  CPC.K=CPC.J+(DTHCR.JK-DR.JK> 

1210N  CPC=0 

1 220N0TE  DISPOSITION  RATE 
1230R  DR . KL= ( CPC . K*DRF ) /DF . K 
1240C  DRF-.025 

1 250NOTE  DISPOSITION  RATE  FRACTION  BASED  ON  8  HRS  TO  EVALUATE 
1 260N0TE  DISPOSITION  FACTORS 

U70A  DF.K*tUSE.K^PER.K»RIQ.K*CNH.**CHT.K+PLA.K)/AAN 
1 280N0TE  CORRECTION  ACTION 
1 290L  C A . K=CA . J+  (  DT ) ( DR. JK-C AR . JK ) 

1300N  CA=0 

1310NOTE  CORRECTIVE  ACTION  RATE 
1320R  CAR.KL-<CA.K*CAF)/CF.K 
1330C  CAF=.OOS 

1 340NOTE  CORRECTIVE  ACTION  FRACTION  BASED  ON  1  PER  UEEK 
1 350N0TE  CORRECTIVE  ACTION  FACTORS 
1 360A  CF.K*<DES.K*CHM.K+DOC.K+PER.K+REG.K*MA.K-*-HGT.K* 

1370X  TES.K+USE.KJ/AAO 
1 380N0TE  CONFIGURATION  CONTROL  BOARD 
1390L  CCB.K=CCB. JMDT) (CAR. JK-CDR.JK) 

1400N  CCB=0 

1410NOTE  CONFIGURATION  CONTROL  BOARB  DIRECTIVE  RATE 
1420R  CDR.KL=(CCB.K*CDF)/CMF.K 
1430C  CDF =.05 

1440M0TE  CCD  FRACTION  BASED  ON  UEEKLY  MEETING  OF  TEN  ITEMS 

1 450N0TE  CCS  MANAGEMENT  FACTORS 

1440A  CMF.K=(USE.K+CHM.K+PLA.K+CNT.K)/AAP 

1 470N0TE  SOFTUARE  RELEASE 

1480L  REL.K=REL. J+(DT) (CDR. JK-SRR. JK) 

1490N  REL*0 

15D0N0TE  SOFTUARE. RELEASE  RATE 


1  SI  OR  SRR.KL«<REL.K*SRF)/$F.K 
1320C  SRF«.025 

1530NOTE  RELEASE  FRACTION  BASED  ON  TUO  WEEKS  TO  RELEASE  SOFTWARE 
1 540N0TE  SOFTWARE  RELEASE  FACTORS 
1 SSOA  SF.K»(CNT.K*DOC.K+PER.K+USE.K*REQ.K)/AAL 
1 560PL0T  HNE*M/CPS*C/CPC*P/CA*A/CCB*B/REL*R 
1 370SPEC  DT=2/LENGTH*208/PLTPER32 
1 380RUN 
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